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FOREWORD 


W  • 


THE  UNITED  STATES  AIR  FORCE  HAS  COMMITTED  ITSELF  TO  "STANDARDIZATION.” 
THE  THEME  OF  THIS  YEAR'S  CONFERENCE  IS  "RATIONAL  STANDARDIZATION,"  AND  WE 
HAVE  EXPANDED  THE  SCOPE  TO  INCLUDE  US  ARMY,  US  NAVY  AND  NATO  PERSPECTIVES 
ON  ONGOING  DOD  INITIATIVES  IN  THIS  IMPORTANT  AREA. 


WHY  DOES  THE  AIR  FORCE  SYSTEMS  COMMAND  SPONSOR  THESE  CONFERENCES? 
BECAUSE  WE  BELIEVE  THAT  THE  COMMUNICATIONS  GENERATED  BY  THESE  GET-TOGETHERS 
IMPROVE  THE  ACCEPTANCE  OF  OUR  NEW  STANDARDS  AND  FOSTERS  EARLIER,  SUCCESSFUL 
IMPLEMENTATION  IN  NUMEROUS  APPLICATIONS.  WE  WANT  ALL  PARTIES  AFFECTED  BY 
THESE  STANDARDS  TO  KNOW  JUST  WHAT  IS  AVAILABLE  TO  SUPPORT  THEM:  THE 
HARDWARE;  THE  COMPLIANCE  TESTING;  THE  TOOLS  NECESSARY  TO  FACILITATE  DESIGN, 
ETC.  WE  ALSO  BELIEVE  THAT  FEEDBACK  FROM  PEOPLE  WHO  HAVE  USED  THEM  IS 
ESSENTIAL  TO  OUR  CONTINUED  EFFORTS  TO  IMPROVE  OUR  STANDARDIZATION  PROCESS. 
WE  HOPE  TO  LEARN  FROM  OUR  SUCCESSES  AND  OUR  FAILURES;  BUT  FIRST,  WE  MUST 
KNOW  WHAT  THESE  ARE  AND  WE  COUNT  ON  YOU  TO  TELL  US. 


AS  WE  DID  IN  1980,  WE  ARE  FOCUSING  OUR  PRESENTATIONS  ON  GOVERNMENT 
AND  INDUSTRY  EXECUTIVES,  MANAGERS,  AND  ENGINEERS  AND  OUR  GOAL  IS  TO 
EDUCATE  RATHER  THAN  PRESENT  DETAILED  TECHNICAL  MATERIAL.  WE  ARE  STRIVING 
TO  PRESENT,  IN  A  SINGLE  FORUM,  THE  TOTAL  AFSC  STANDARDIZATION  PICTURE  FROM 
POLICY  TO  IMPLEMENTATION.  WE  HOPE  THIS  INSIGHT  WILL  ENABLE  ALL  OF  YOU  TO 
BETTER  UNDERSTAND  THE  "WHY'S  AND  WHEREFORE'S"  OF  OUR  CURRENT  EMPHASIS  ON 
THIS  SUBJECT. 


MANY  THANKS  TO  A  DEDICATED  TEAM  FROM  THE  DIRECTORATE  OF  AVIONICS 
ENGINEERING  FOR  ORGANIZING  THIS  CONFERENCE;  FROM  THE  OUTSTANDING  TECHNICAL 
PROGRAM  TO  THE  UNGLAMOROUS  DETAILS  NEEDED  TO  MAKE  YOUR  VISIT  TO  DAYTON,  OHIO 
A  PLEASANT  ONE.  THANKS  ALSO  TO  ALL  THE  MODERATORS,  SPEAKERS  AND  EXHIBITORS 
WHO  RESPONDED  IN  SUCH  A  TIMELY  MANNER  TO  ALL  OF  OUR  PLEAS  FOR  ASSISTANCE. 


ROBERT  P.  LAVOIE,  COL,  USAF 
DIRECTOR  OF  AVIONICS  ENGINEERING 
DEPUTY  FOR  ENGINEERING 
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2  3  AUG  1S3? 


Second  AFSC  Standardization  Conference 


ASD/CT 

1.  Since  the  highly  successful  standardization  conference  hosted  by  ASD  in 
1980,  significant  technological  advancements  have  occurred.  Integration  of 
the  standards  into  weapon  systems  has  become  a  reality.  As  a  result,  we  have 
many  "lessons  learned"  and  cost /benefit  analyses  that  should  be  shared  within 
the  tri-service  ooranunity.  Also,  this  would  be  a  good  opportunity  to  update 
current  and  potential  "users."  Therefore,  I  endorse  the  organization  of  the 
Second  PFSC  Standardization  Conference. 

2.  This  conference  should  cover  the  current  accepted  standards,  results  of 
recent  congressional  actions,  and  standards  planned  for  the  future.  We  should 
provide  the  latest  information  an  policy,  system  applications,  and  lessons 
learned.  The  agenda  should  accomodate  both  government  and  industry  inputs 
that  criticize  as  well  as  support  our  efforts.  Experts  from  the  tri-service 
arena  should  be  invited  to  present  papers  an  the  various  topics.  Our  AFSC 
project  officer,  Maj  David  Hanmond,  HQ  PFSC/ALR,  AOTOVON  858-5731,  is  prepared 
to  assist. 


ROBERT  M.  BOND,  Lt  Gen,  USA£ 

Vice  Commander 
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April  26,  1976 
NUMBER  5000.29 


ASD(I&L) 


'MiisO' 


SUBJECT 


Department  of  Defense  Directive 


Management  of  Computer  Resources 
in  Major  Defense  Systems 


References:  (a)  through  (m)  are  listed  in  enclosure  4 

I.  PURPOSE 

This  Directive  establishes  policy  for  the  management  and 

control  of  computer  resources  during  the  development, 

acquisition,  deployment  and  support  of  major  Defense  systems. 

II.  APPLICABILITY  AND  SCOPE 

A.  The  provisions  of  this  Directive  apply  to  the  Office  of 
the  Secretary  of  Defense,  the  Military  Departments,  the 
Organization  of  the  Joint  Chiefs  of  Staff,  and  the  Defense 
Agencies  (hereinafter  referred  to  collectively  as  "DoD 
Components"). 

B.  Its  provisions  encompass  major  programs  of  Defense 
systems  acquisition,  as  designated  by  the  Secretary  of 
Defense  (described  in  section  II.  of  DoD  Directive 
5000.1,  reference  (a)).  In  addition,  it  provides 
principles  to  be  applied  in  the  acquisition  of  Defense 
systems  that  do  not  fall  in  the  "major  acquisition 
category." 

C.  Excluded  from  the  provisions  of  this  Directive  are 
general  purpose,  commercially  available  automatic  data 
processing  assets  as  defined  and  administered  under 
CMB  Circular  A-71,  DoD  Directives  1*105.55,  4160.19, 
and  5100.40  (references  (b),  (c),  (d),  and  (e)).  How¬ 
ever,  when  feasible,  the  terms,  tools,  and  techniques 
employed  in  the  general  purpose  area  will  be  adopted 
or  adapted  to  support  management  of  computer  resources 
in  major  Defense  systems. 

HI.  DURATION 

It  is  intended  that  the  policies  and  principles  embodied 
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In  this  Directive  ultimately  he  assimilated  as  an  integral  pert 
of  the  established  process  of  acquiring  major  Defense  systems. 
Therefore,  the  continuing  need  for  this  Directive,  and  all  organize- 
tional  Institutions  created  herein  6hall  be  reviewed  biannually  with 
a  view  toward  cancellation  after  6  years.  DoD  Directives  5000.1, 
5000.2,  and  5000.3  (references  (a),  (g),  and  (h))  will  be  modified  as 
appropriate,  to  reflect  this  assimilation. 

IV.  DEFINITIONS 


Terms  used  in  this  Directive  are  defined  in  enclosure  1. 
V.  POLICY 

A.  General 


1.  Annual  expenditures  by  DoD  on  the  design,  development,  acqui¬ 
sition,  management,  and  operational  support  of  computer  resources 
embedded  within,  and  integral  to  weapons,  ccmnunlcatlons,  com¬ 
mand  and  control,  and  intelligence  sensor  systems  are  measured 

in  the  billions  of  dollars.  Unreliability,  particularly  of 
software,  diminshes  DoD  mission  effectiveness  in  many  major 
Defense  systems. 

2.  Computer  resources  in  Defense  systems  must  be  managed  as  ele¬ 
ments  or  subsystems  of  major  importance  during  conceptual, 
validation,  full-scale  development,  production,  deployment, 
and  support  phases  of  the  life  cycle,  with  particular  emphasis 
on  computer  software  and  its  integration  with  the  surrounding 
hardware. 

B.  Requirements  Validation  and  Risk  Analysis 

1.  Validation  of  computer  resource  requirements.  Including  soft¬ 
ware,  risk  analyses,  planning,  preliminary  design,  security 
where  applicable  (DoD  Directive  5200.28,  reference  (f))  and 
interface  control  and  integration  methodology  definition  will 
be  conducted  during  the  Concept  Formulation  and  Program 
Validation  phases  of  Defense  system  development,  prior  to 
Defense  Systems  Acquisition  Review  Council  (D6ARC;  II. 

2.  This  analysis  must  assure  conformance  of  planned  computer 
resources  with  stated  operational  requirements. 

3.  Risk  analysis,  preliminary  design,  hardware /software  inte¬ 
gration  methodology,  external  interface  control,  security 
features  (DoD  Directive  5200.28,  reference  (f)),  and  life 
cycle  system  planning  shall  he  included  in  the  review. 

U.  Correctness  of  software,  r®1 lability,  integrity,  maintain¬ 
ability,  ease  of  modificat.-..,  and  transferability  will  be 
major  considerations  in  the  initial  design. 

5.  The  risk  areas,  and  a  plan  for  their  resolution  shall  he 
included  in  the  Decision  Coordinating  Paper  (DoD  Directive 
5000.2,  reference  (g)). 

6.  In  addition,  computer  resource  requirements  will  be  continu¬ 
ously  coordinated  and  reconciled  with  system  operational 
requirements  throughout  system  development  after  DSARC  II. 

C.  Configuration  Management  of  Computer  Resources.  Defense  system 
computer  resources/  including  both  computer  hardware  and  computer 
software  will  be  specified  and  treated  as  configuration  items. 
Baseline  implementation  guidance  for  this  action  is  contained  In 
L  U  Instruction  5010.21  (reference  (i)). 

0.  jputer  Resource  Life  Cycle  Planning.  A  computer  resource  plan 
11  be  developed  prior  to  D6ARC  II,  and  will  be  maintained 
throughout  the  life  cycle.  The  purpose  of  the  plan  is  to  identify 
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important  Defense  system  computer  resources  acquisition  and  life 
cycle  planning  factors,  both  direct  and  indirecti  and  to  establish 
specific  guidelines  to  ensure  that  these  factors  are  adequately 
considered  in  the  acquisition  planning  process.  Examples  of  factors 
to  be  addressed  are  the  following,  as  applicable: 

1.  Responsibilities  for  integration  of  computer  resources  into  the 
total  Defense  system  and  the  determination  of  overall  system 
quality  and  integrity. 

2.  Personnel  requirements  for  developing  and  supporting  computer 
resources . 

3.  Computer  programs  required  to  support  the  development,  acquisi¬ 
tion,  and  maintenance  of  computer  equipment  and  other  computer 
programs . 

4.  Provisions  for  the  transfer  of  program  management  responsibility 
after  initial  system  operating  capability  has  been  achieved;  pro¬ 
visions  for  system/equipment  turnover. 

Support  Software  Deliverables.  Unique  support  items  required  to  cost 
effectively  develop  and  maintain  the  delivered  computer  resources 
over  the  system's  life  cycle  will  be  specified  as  deliverable,  with 
DoD  acquiring  rights  to  their  design  and/or  use.  Examples  of  such 
support  items  are  compilers,  environmental  simulators,  documentation 
aids,  test  case  generators  and  analyzers,  and  training  aids.  The 
provisions  of  ASPR,  section  IX  (reference  (j))  shall  govern  the 
implementation  of  the  policy. 

Milestone  Definition  and  Attainment  Criteria.  Specific  milestones 
to  manage  the  life  cycle  development  of  computer  resources,  including 
computer  system  and  support  software  will  be  used  to  ensure  the  proper 
sequence  of  analysis,  design,  implementation,  integration,  test,  docu¬ 
mentation,  operation,  maintenance,  and  modification.  These  milestones 
will  include  specific  criteria  that  measure  their  attainment. 

Sofware  Language  Standardization  and  Control.  Do D  approved  High  Order 

Programming  Languages  (HOLs) ,  (reference  (k))  will  be  used  to  develop 
Defense  system  software,  unless  it  is  demonstrated  that  none  of  the 
approved  HOLs  are  cost  effective  or  technically  practical  over  the 
system  life  cycle.  Each  DoD  approved  HOL  will  be  assigned  to  a 
designated  control  agent  who  will  be  responsible  for  such  activities 
as  validating  compliance  of  compiler  implementations  with  the  standard 
language  specifications,  gathering  data  as  to  the  use  of  the  language, 
and  for  disseminating  Information,  compilers,  and  tools.  The  designated 
control  agent  will  also  be  responsible  for  assuring  language  stability 
except  for  DoD  HOL  specifications  which  already  fall  within  the  purview 
of  DoD  Manual  4120. 3M  (reference  (m)). 


VI. 


RESPONSIBILITIES 


A.  In  order  to  oversee  and  coordinate  the  accomplishment  of  poli¬ 
cies  in  this  Directive  and  the  incorporation  of  its  principles 
into  the  normal  Defense  system  acquisition  process,  a  Manage¬ 
ment  Steering  Committee  for  Embedded  Computer  Resources  is 
hereby  established.  This  Committee  shall  operate  under  the 
Charter  of  enclosure  2  for  a  period  not  to  exceed  the  life  of 
this  Directive. 

B.  DoD  Components  will  review  their  existing  regulations,  speci¬ 
fications,  and  standards  modifying,  cancelling,  or  supple¬ 
menting  them  as  required  to  ensure  consistency  with  the  policy 
in  this  Directive. 

C.  DoD  Components  will  develop  and  implement  a  disciplined 
approach  to  the  management  of  software  design,  engineering, 
and  programming  which  will  ensure  the  provision  of  effective 
software  at  minimum  life  cycle  cost.  To  assist  in  the 
achievement  of  this  objective,  DoD  Components  will,  as  a 
minimum: 

1.  Prepare  and  maintain  appropriate  guidance  documents  (e.g., 
guidelines,  checklists,  handbooks,  and  descriptive 
examples)  covering  requirements  definition,  development, 
acquisition,  operation,  and  support  issues  attendant  to 
computer  software  in  Defense ' systems .  These  documents 
should  be  available  for  use  as  necessary  by  program 
managers  and  tneir  staffs  as  well  as  organiza"  x.r  tasked 
with  specific  responsibility  for  developing,  acquiring, 
operating,  and  supporting  the  computer  resource  elements. 

2.  Establish  and/or  maintain  appropriate  education,  training, 
and  experience  career  paths  with  accompanying  career  in¬ 
centives  to  foster  the  development  and  retention  of  pro¬ 
fessional  computer  resource  engineers,  managers,  and 
technicians . 

3.  Plan  and  execute  a  coordinated  research  and  development 
program  to  identify  and  supply  the  technological  base 
needed  to  support  the  policy,  practice,  and  procedure  re¬ 
requirements  of  this  Directive.  This  coordination  will 
be  accomplished  using  the  Technology  Coordinating  Paper 
(reference  (k)). 

VII.  EFFECTIVE  DATE  AND  IMPLEMENTATION 

This  Directive  is  effective  immediately.  Five  copies  of  the 
implementation  plan  shall  be  forwarded  to  the  Assistant  Secre¬ 
tary  of  Defense  (Installations  and  Logistics)  for  approval, 
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prior  to  issuance.  Five  copies  of  the  final  implementation  plan 
shall  be  forwarded  to  the  ASD(I&L)  within  90  days. 


JV-T 

Deputy  Se 

Enclosures  -  4 

1.  Definitions 

2.  Charter 

3.  DDR&E  Memorandum,  "Technology  Coordinating 

Papers,"  May  29,  1974 

4.  List  of  References 
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DEFINITI®S 


A.  Computer  Data.  Basic  elements  of  information  used  by  computer 
equipment  in  responding  to  a  computer  program. 

B.  Computer  Equipment.  Devices  capable  of  accepting  and  storing  com¬ 
puter  data,  executing  a  systematic  sequence  of  operations  on  com¬ 
puter  data  or  producing  control  outputs.  Such  devices  can  perform 
substantial  interpretation,  computation,  communication,  control, 
and  other  logical  functions. 

C.  Computer  Firmware .  The  logical  code  of  computer  equipment  which  in¬ 
terprets  the  control  functions  of  that  equipment. 

D.  Computer  Program.  A  series  of  instructions  or  statements  in  a  form 
acceptable  to  computer  equipment,  designed  to  cause  the  execution 
of  an  operation  or  series  of  operations.  Computer  programs  include 
such  items  as  operating  systems,  assemblers,  compilers,  interpret¬ 
ers,  data  management  system,  utility  programs,  and  maintenance/ 
diagnostic  programs.  They  also  include  application  programs  such 
as  payroll,  inventory  control,  operational  flight,  strategic, 
tactical,  automatic  test,  crew  simulator,  and  engineering  analysis 
programs.  Computer  programs  may  be  either  machine  dependent  or 
machine  independent,  and  may  be  general  purpose  in  nature  or  be 
designed  to  satisfy  the  requirements  of  a  specialized  process  of  a 
particular  user. 

E.  Computer  Resources .  The  totality  of  computer  equipment,  computer 
program,  computer  data,  associated  documentation,  personnel,  and 
supplies . 

F.  Computer  Software.  A  combination  of  associated  computer  programs 
and  computer  data  required  to  enable  the  computer  equipment  to 
perform  computational  or  control  functions. 

G.  Embedded .  Adjective  modifier;  integral  to,  from  the  design,  pro¬ 
curement,  and  operations  point  of  view  espoused  in  DoD  Directive 
5000.1  (reference  (a)). 

H.  Software  Engineering.  Science  of  design,  development,  implementa¬ 
tion,  test,  evaluation,  and  maintenance  of  computer  software  over 
its  life  cycle. 


sssl 
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CHARTER  OF 

DQD  MANAGEMENT  STEERING  COMMITTEE 
FOR 

EMBEDDED  CCMFUTER  RESOURCES 

BACKGROUND 

Current  annual  expenditures  by  the  Department  of  Defense  on  the 
design,  development,  acquisition,  management  and  operation  sup¬ 
port  of  computer  resources  embedded  within  and  integral  to 
weapons,  communications,  command  and  control,  and  intelligence 
systems  are  measured  in  the  billions  of  dollars.  At  the  same 
time  such  computer  resources  have  often  presented  critical  cost 
and  schedule  problems  during  the  development  and  acquisition  of 
new  defense  systems.  Even  after  system  implementation  and  field¬ 
ing  the  software  has  often  proven  unreliable.  To  correct  these 
problems  and  to  improve  the  management  of  embedded  computer 
resources  in  general,  a  DoD  management  steering  committee  is 
hereby  formed.  This  committee  will  be  responsible  for  imple¬ 
menting  this  Directive  and  will  operate  under  the  provisions  of 
this  Charter. 

SCOPE 

A.  The  Management  Steering  Committee  for  Embedded  Computer 
Resources  (MSC-ECR  )i/  shall  implement  the  provisions  of  this 
Directive  and  issue  ensuing  policies  related  to  computer 
resources  which  are  embedded  within  major  Defense  weapon, 
command,  control,  communications,  and  intelligence  systems. 

B.  The  MSC-ECR  activities  will  not  encompass  the  field  of 
general  purpose,  commercially  available  Automatic  Data 
Processing  Equipment  (ADPE)  as  defined  and  administered  by 
references  (a),  (b),  (c),  and  (d)  of  this  Charter.  Working 
level  interfaces  will  be  maintained  with  the  ADPE  Community, 
however,  to  ensure  maximum  transferability  of  ideas  and  cross¬ 
utilization  of  products. 

OBJECTIVES 

The  objectives  of  the  MSC-ECR  are  fourfold: 

A.  Improve  the  management  of  computer  resources  embedded  in 
major  Defense  systems. 


Formerly  named  "Weapon  Systems  Software  Management  Steering 
Committee . " 


.\ 
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B.  Increase  visibility  of  computer  resources  in  overall  system 
acquisitions . 

C.  Formulate  a  coordinated  DoD  Technology  Base  Program  for  soft¬ 
ware  basic  research,  exploratory  development,  advanced  devel¬ 
opment,  and  technology  demonstrations  addressing  critical 
software  issues  that  can  be  recommended  to  the  Director, 
Defense  Research  and  Engineering. 

D.  Guide  the  assimilation  and  integration  of  computer  resource 
policy,  practice,  procedure,  and' technology  into  the  normal 
process  of  major  Defense  systems  acquisition. 

ACTIVITIES 

In  carrying  out  the  objectives  of  section  III.,  the  MSC-ECR 

shall : 

A.  Develop  proposed  future  policies,  or  changes  to  existing  pol¬ 
icies  as  may  be  necessary'  for  the  acquisition  and  management 
of  embedded  computer  resources  in  major  Defense  systems,  and 
oversee  the  implementation  of  policies  stated  in  this 
Directive . 

B.  Advise  the  Principals  of  the  Defense  System  Acquisition  Review 
Council  on  general  policy  matters  and  on  specific  embedded 
computer  resource  issues  related  to  major  Defense  Systems. 

C.  Provide  recommendations  and  advice  to  DDR&E  on  Computer 
resource  R&D  technology  programs. 

D.  Provide  a  focal  point  for  inter-  and  intra-Service  coordina¬ 
tion  on  policy  and  management  issues. 

E.  Coordinate  technology  efforts  among  DoD  Components. 

F.  Review  DoD  Component  activities  for  compliance  with  the  pro¬ 
visions  of  this  Directive. 

ORGANIZATION  &  CCMP0SITI0N 

The  MSC-ECR  shall  be  composed  of  an  Executive  Board  and  a  Manage¬ 
ment  Advisory  Board,  assisted  as  necessary  by  technical  panels 

working  in  areas  of  specialized  expertise. 

A.  The  Executive  Board  shall  consist  of  one  designated  repre¬ 
sentative  from  Assistant  Secretary  of  Defense (Installations 
and  Logistics),  DDR&E,  Director,  Telecommunications  and 
Command  and  Control  Systems,  Assistant  Secretary  of  Defense 
(Comptroller),  and  Assistant  Secretary  of  Defense(lntelli- 
gence).  The  Executive  Board  will  be  chaired  by  ASD(I&L). 

All  decision-making  power  of  the  MSC-ECR  shall  be  vested 
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in  the  Executive  Board;  opinions  and  decisions  of  the  Board 
will  be  expressed  by  the  chairman,  acting  as  principal  spokes¬ 
man  for  the  MSC-ECR,  and  will  be  based  on  concurrence  of  all 
Board  members.  If  concurrence  cannot  be  achieved,  the 
divergent  views  will  be  forwarded  with  majority  and  minority 
reports  for  resolution  by  OSD  staff  principals  or  the  Deputy 
Secretary  of  Defense. 

B.  The  Management  Advisory  Board  shall  consist  of  representatives 
of  DoD  Components  as  follows: 

Army 
Navy 

Air  Force 

Office  of  the  Joint  Chiefs  of  Staff 
Defense  Communications  Agency 
National  Security  Agency 
Defense  Advanced  Research  Projects  Agency 
TRI-TAC 

Deputy  Director  (Test,  and  Evaluation), 

ODDRScE 

RESPONSIBILITIES 

Responsibilities  pursuant  to  the  provision  of  this  Charter  and  of 

this  Directive  shall  be  as  follows: 

A.  The  Executive  Board  of  the  Management  Steering  Committee  shall: 

1.  Develop  policy,  or  changes  to  existing  policy  as  may  be 
necessary  for  the  acquisition  and  management  of  computer 
resources  in  major  Defense  systems,  and  oversee  their 
accomplishment . 

2.  Advise  the  Principals  of  the  Defense  Systems  Acquisition 
Review  Council  on  general  policy  matters  and  on  specific 
computer  resource  issues  applicable  to  DSARC-managed 
programs . 

3.  Provide  recommendations  and  advice  to  the  Director  Defense 
Research  and  Engineering  on  computer  resource  R&D  tech¬ 
nology  programs . 

4.  Review  DoD  Component  activities  for  compliance  with  the 
provisions  of  this  Directive. 

5.  Assist  the  Chairman  of  the  OSD  Cost  Analysis  Improvement 
Group  (CAIG)  in  preparing  independent  cost  estimates  for 
major  Defense  Systems. 


3  members 
3  members 
3  members 

1  member 

2  members 
2  members 
2  members 
1  member 

1  member 
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B.  The  Management  Advisory  Board  of  the  Management  Steering 
Committee  shall,  for  major  Defense  Systems: 

1.  Conduct  policy  impact  assessments  and  analyses  for  the 
Executive  Board  in  both  technical  and  managerial  areas 
relating  to  computer  resources. 

2.  Serve  as  focal  points  for  inter-  and  intra-Service  coor¬ 
dination  on  policy  and  management  issues . 

3.  Coordinate  technology  efforts  among  DoD  Components. 

4.  Review  computer  resource  technology  programs  for  policy 
consistency,  relevancy  and  impact;  advise  Executive 
Board  of  meaningful  technology  findings,  results,  and 
product  developments . 

5.  Publicize  appropriate  management  and  technological 
developments  related  to  computer  resources,  throughout 
DoD  and  industry. 

C.  The  Management  Advisory  Board  will  assist  the  Executive 
Board  in  fulfulling  the  objectives  of  the  MSC-ECR,  and  the 
members  will  act  as  focal  points  for  their  respective  DoD 
Components  in  the  areas  of  embedded  computer  resources. 

VII.  TECHNICAL  PANELS 


Adhoc  Technical  Panels  may  be  formed  at  the  direction  of  the 
MSC-ECR  to  examine  problems  requiring  specialized  and  detailed 
expertise.  Any  panel  so  formed  will  be  governed  by  its  own 
Charter,  which  must  be  approved  by  the  Executive  Board,  and 
will  report  to  the  membership  of  the  MSC-ECR.  An  appropriate 
Chairman  of  the  Executive  Board.  Membership  on  the  panel  will 
be  determined  by  the  Panel  Chairman,  and  may  be  drawn  from  the 
DoD  Components  or  from  industry  as  appropriate  for  the  task  at 
hand. 

VIII.  METHOD  OF  OPERATION 


A.  The  MSC-ECR  shall  meet  quarterly,  or  upon  the  call  of  the 
Chairman.  The  agenda  will  be  set  by  the  presiding  Chairman, 
with  concurrence  by  members  of  the  Executive  Board. 

B.  The  ASD(I&L) ,  or  his  designated  representative  shall  act  as 
Executive  Secretary  to  the  MSC-ECR,  and  shall  be  responsi¬ 
ble  for  preparing  the  minutes  and  administering  the  overall 
affairs  of  the  committee.  Minutes  of  all  -etings  shall  be 
distributed  no  later  than  30  calendar  days  after  the  subject 
meeting  is  adjourned.  The  ASD(I&L)  shall  provide  adminis¬ 
trative  support  to  the  MSC-ECR. 
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DEFINITIONS 


The  terms  defined  in  the  basic  Directive  shall  be  applicable  to 
this  Charter  and  the  functioning  of  the  MSC-ECR. 

REFERENCES 


A.  Office  Management  Budget  Circular  A-71,  "Responsibilities  for 
the  Administration  and  Management  of  Automatic  Data  Processing 
Activities,"  March  6,  1965 

B.  DoD  Directive  5100.40,  "Responsibilities  for  the  Administration 
of  the  DoD  Automatic  Data  Processing  Program,"  August  19,  1975 

C.  DoD  Directive  4105.55,  "Selection  and  Acquisition  of  Automatic 
Data  Processing  Resources,"  April  5,  1973 

D.  DoD  Directive  4160.19,  "Department  of  Defense  Automatic  Data 
Processing  Equipment  Reutilization  Program,"  April  5,  1973 
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29  may  1974 


MEMORANDUM  FOR  Assistant  Secretaries  of  the  Military  Departments  (R&D) 

Director,  Defense  Advanced  Research  Projects  Agency 
Director,  Defense  Nuclear  Agency 
Director,  Defense  Intelligence  Agency 

SUBJECT:  Technology  Coordinating  Papers 


The  concept  of  Technology  Coordinating  Papers  has  been  evolving  for  more 
than  four  years.  In  this  period,  essentially  one  of  trial  and  error,  the 
concept  has  been  clarified  and  certain  problems  associated  with  the  overall 
implementation  have  been  surfaced.  As  a  result,  we  are  now  in  a  better 
position  to  restate  the  general  requirements  for  TCP's,  their  utilization, 
their  content,  the  management  of  the  TCP  process,  the  review  and  critique 
process,  and  the  distribution  of  the  coordinated  documents.  This  memo¬ 
randum  provides  the  overall  guidance  to  DoD  personnel  involved  in 
preparation  or  revision  of  those  TCP's  either  in  process  or  planned  for 
the  future,  and  supersedes  prior  memoranda  of  19  January  1972,  18  August 
1972,  and  29  March  1973  on  this  subject. 

GENERAL  REQUIREMENTS  FOR  TCP's 

The  TCP's  which  have  been  published  are  proving  invaluable  to  R&  D 
managers  as  the  best  means  to  provide  a  bounded  overview  of  selected 
segments  of  the  DoD  technology  base.  TCP's  have  served  to  answer  the 
following  questions: 

•  Are  there  needless  overlaps  and  duplications? 

•  Are  there  vital  defense  research  areas  which  are  underfunded 
and  even  missing  from  the  base? 

•  Are  sufficient  coordination  and  interchange  taking  place  among 
the  Services  to  maximize  the  return  from  resources  being 
applied  to  a  given  area0 
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•  Are  the  priorities  set  correctly;  that  is,  are  the  spending  levels 
for  the  various  areas  consistent  with  the  requirements  in  those 
areas  ? 

•  Are  future  weapon  system  requirements  being  acknowledged  in 
the  more  applied  work  being  conducted  within  the  technology 
base  ? 

•  How  does  the  overall  program  match  priorities  and  mission  area 
deficiencies  ? 

These  are  the  kinds  of  questions  which  are  of  concern  to  both  the  DDR&E 
and  the  Assistant  Secretaries  (R&D)  &  Military  R&D  Chiefs  of  the  Military 
Departments  who  are  responsible  for  overseeing  the  Service  programs. 

In  addition,  the  Secretary  of  Defense  and  the  Congress  have  questions 
concerning  the  relative  value  of  the  diverse  activities  contained  in  the 
technology  base  --  questions  which  can  best  be  answered  by  showing 
how  the  various  pieces  fit  together  to  make  a  coherent  whole.  The 
TCP's  have  also  served  as  a  device  for  improving  interservice  and 
Defense  Agency  communications  in  most  technology  areas.  In  some 
areas,  information  from  the  TCP's  has  also  provided  the  basis  for  the 
dissemination  of  information  on  technology  programs  and  future  needs 
to  the  industrial  and  academic  sectors.  For  these  reasons,  we  shall 
continue  to  prepare  TCP's  in  the  following  technology  base  program 
areas: 


Propulsion  Technology,  Missiles  and  Space  Vehicles 
Medical  and  Biological  Sciences 
Materials  Technology 
Structures  Technology 
Aircraft  Propulsion  Technology 
Aeronautical  Vehicle  Technology 
Human  Resources  Technology 
Environmental  Sciences 
Electronic  Devices 
Weapons  Technology 
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•  Surface  Vehicles 

•  Electronics  Technology  (to  be  initiated  in  FY  1975) 
UTILIZATION  OF  TCP's 


While  TCP's  have  proved  an  effective  mechanism  for  spotting  duplicative, 
underfunded,  or  missing  programs,  they  have  not  generally  fulfilled  one 
of  the  originally  intended  roles;  that  of  forming  a  basis  for  organizing 
work  in  specific  segments  of  the  technology  base  where  appreciable 
multi-Service  activity  or  interest  exists.  Neither  have  they  been  optimally 
utilized  by  all  levels  of  Service  R&D  Management  as  an  aid  in  making 
decisions  on  prudent  allocation  of  resources  in  the  various  technology  areas. 
Only  in  some  cases  have  TCP's  been  used  as  data  bases  for  the  general 
planning  process  at  the  Service  staff  and  systems  command  levels.  In 
short,  it  does  not  appear  that  middle  management  in  the  Services  has  taken 
full  advantage  of  the  information  contained  in  the  TCP  documents.  This 
deficiency  could  be  corrected  if  the  TCP's  were  made  a  part  of  the  basic 
documentation  for  use  at  all  management  levels  in  the  preparation  of  budget 
and  apportionment  plans.  Additionally,  the  utilization  of  TCP  information 
in  the  preparation  of  overall  investment  strategy  analyses  for  specific 
technology  areas  would  be  a  valuable  adjunct  to  the  planning  documents  of 
the  individual  Services. 

CONTENT  OF  TCP's 


The  use  of  a  standard  format  or  a  standard  table  of  contents  for  a  TCP 
is  not  required.  The  format  should  be  the  prerogative  and  responsibility 
of  the  Service/Agency  team  preparing  the  TCP.  However,  if  the  objectives 
of  the  TCP  process  are  to  be  achieved,  these  documents  should  contain  at 
least  the  following  information; 

•  An  examination  of  the  impact  of  both  near  term  and  future 
military  requirements  by  mission  area  as  they  might 
influence  that  technology. 

•  A  description  of  the  current  and  future  DoD  program  in  that 
technology  area  and  the  degree  to  which  the  program  satisfies 
firm  military  requirements,  ’this  should  include  a  summary 
of  work  content,  designation  of  the  sponsoring  Service  or 
Defense  Agency  for  major  tasks,  and  where  these  tasks  are 
being  performed  (in-house  or  major  contractors,  by  name). 
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Within  this  description  an  explicit  discussion  of  the  motivations 
and  relevancy  of  the  6.  1  Research  projects  should  be  given. 

The  TCP  should  also  highlight  the  non- system  6.  3  Advanced 
Technology  Demonstration  projects  with  appropriate  discussions 
as  to  their  potential  payoff  in  terms  of  improved  operational 
capability,  cost  reduction,  or  cost  avoidance. 

•  A  summary  table  matrix  which  correlates  technical  sub-areas 
with  sponsor.  Program  Element,  and  Project  number.  Because 
of  the  problems  associated  with  the  distribution  of  outyear  fiscal 
data,  TCP's  will  be  written  to  contain  financial  data  for  only  the 
current  and  budget  years.  Data  from  preceding  fiscal  years 
should  be  selectively  included  to  indicate  significant  trends. 
Complete  FYDP  data  will  not  be  shown  in  the  TCP,  although 
anticipated  trends  in  funding  levels  may  be  indicated  either 
quantitatively  or  qualitatively.  This  restriction  is  not  meant 

to  exclude  the  consideration  of  FYDP  data  in  the  preparation 
of  a  TCP,  which  can  be  very  useful,  or  to  inhibit  publication 
of  FYDP  data  in  an  appendix  or  supplement  to  the  TCP. 

•  Identification  and  description  (if  available)  of  other  DoD 
programs  (i.  c.  ,  Manufacturing  Technology,  Component 
Improvement,  etc.  )  non-DoD  programs  (NASA,  AEC,  NSF, 
etc.  )  or  other  major  efforts  (IR&tD),  if  any,  which  have  a 
significant  impact  on  the  technology  area,  and  an  assessment 
of  that  impact. 

•  A  short  assessment  of  the  technology  area  itself,  including 
mission  area  deficiencies,  a  brief  recount  of  significant 
historical  trends  and  expected  future  trends,  significant 
recent  accomplishments  and  (where  instructive)  significant 
recent  negative  results. 

No  restrictions  on  the  size  of  TCP's  can  reasonably  be  imposed.  Some 
TCP's  will  be  comprised  of  a  single  document  of  perhaps  50-80  pages 
in  length  whereas  others  will  be  as  long  as  several  hundred  pages  because 
of  the  diversity  of  that  technology  area.  All,  however,  should  contain 
an  Executive  Summary  (maximum  of  20-25  pages)  of  the  salient  information 
in  the  document. 

MANAGEMENT  OF  TCP  PROCESS 

•  The  DD(RSiAT)  is  responsible  for  the  overall  implementation 
of  the  TCP  process. 
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•  The  DDfR&AT)  is  responsible  for  ensuring  that  each  basic  TCP 
is  as  concise  as  possible  and  that  all  background  information 

is  prepared  in  a  useful  format. 

•  The  DD(R&AT)  is  responsible  for  determining  the  rate  and 
frequency  of  preparation  of  each  TCP.  Annual  revisions  of 
TCP's  will,  therefore,  not  be  automatic,  but  an  annual  review 
of  each  TCP  will  be  made  to  determine  whether  to  amend, 
update,  rewrite,  supplement  or  make  no  change. 

•  It  is  not  required  that  working  drafts  or  for-comment  drafts 
of  TCP's  be  thoroughly  staffed  or  coordinated  at  the  middle 
or  upper  management  levels.  Forty-five  days  will  be  allowed 
for  review  of  the  coordination  draft  of  each  TCP.  The  Assistant 
Secretaries  (R&D)  of  the  Military  Departments  may,  at  their 
discretion,  delegate  coordination  authority.  I  have  delegated 
the  DDR&E  coordination  authority  to  the  DD(R&AT). 

DISTRIBUTION  OF  TCP's 


•  The  basic  TCP  documents  will  not  be  distributed  to  industry. 

They  will  be  selectively  distributed  to  other  Federal  Agencies 
such  as  NASA,  CIA,  and  NSF  and  to  the  Congress  as  appropriate. 
The  DD(R&AT)  will  determine  the  appropriateness  of  TCP 
distribution  outside  of  DoD. 

•  Initial  and  secondary  distribution  of  coordination  TCPs  will 
be  made  through  the  Defense  Documentation  Center  (DDC). 
Distribution  to  other  than  in-house  organizations  will  require 
the  express  approval  of  DD(R&AT). 

•  Every  effort  will  be  made  to  distribute  TCP  information  (not 
TCP's)  concerning  technology  requirements  to  industry, 
academic  and  other  non-government  personnel.  The  appropriate¬ 
ness  of  these  distributions  will  be  determined  by  DD(R&AT). 

•  Draft  and  coordinated  TCP's  will  be  distributed  to  appropriate 
Service  laboratories.  The  appropriateness  of  these  distributions 
will  be  determined  by  the  Military  Departments. 
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REVIEWS  AND  CRITIQUES  OF  TCP'S 

•  It  shall  be  the  responsibility  >f  ihe  DD(Rh-AT)  to  obtain  critiques 
of  TCP's  as  appropriate.  The  nature  of  these  reviews  will  vary 
with  the  scope  and  content  of  the  individual  TCP.  The  reviewers 
may  be  comprised  of  professional  staff  from  Federal  Contract 
Research  Centers  (FCRC's),  members  of  quasi- government 
institutions  such  as  the  National. Academy  of  Sciences  (NAS), 

or  selected  personnel  from  private  industry  or  academia. 

•  When  members  of  private  industry  or  academia  are  utilized  to 
review  TCP's,  they  will  conduct  their  review  in  the  Pentagon 
and  will  not  be  permitted  to  take  the  documents  from  the  building. 

•  The  results  of  all  such  reviews  will  be  passed  to  the  Military 
Departments  and  appropriate  Defense  agencies  for  information 
and  comment  if  appropriate. 
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(b)  Office  of  Management  and  budget  Circular  A-'l,  "nespor.sibiii?  ies  for 

the  Administration  and  Management  of  Automatic  Data  Process i.ng  Ac¬ 
tivities,"  March  6,  1995 

(c)  DoD  Directive  .'*105 . 55 ,  "Selection  Acquisition  of  Automat  i  .•  In'  u 

Processing  Resources,"  May  19,  log? 

(d)  DoD  Directive  9lo0.19,  "Department  of  iXifer.se  Automat  i  -  Data  i  ro 

cessing  Equipment  Reutilization  Program, "  April  S,  I9f3 

(e)  DoD  Directive  5100.90,  "Responsibility  for  the  Administration  of  the 

DoD  Automatic  Data  Processing  Program,"  August  19,  19T5 

(f)  DoD  Directive  5200.23,  "Security  Requirements  for  Automatic  Data 

Processing  (ADP^  Systems,"  December  13,  lcJf2 

(g)  DoD  Instruction  5000.2,  "The  Decision  Coordinating  Paper  arid  the 

Defense  Systems  Acquisition  Review  Council  (DSARC),"  January  21, 
1975 

(h)  DoD  Directive  5000. 3,  "Test  and  Evaluation,"  January  19,  KV3 

(i)  DoD  Instruction  5010.21,  "Configuration  Management  Implementation 

Guidance,"  August  6,  1963 

(.j)  Armed  Services  Procurement  Regulation,  Section  IX,  Parts  5  and  6 

(k)  DoD  Instruction  5000.31,  "Interim  List  of  DoD  approved  High  Order 

Programming  Languages,"  November  29,  1976 

(l)  Director,  Defense  Research  and  Engineering  Memorandum,  "Technology 

Coordinating  Papers,”  May  29,  1979  (enclosure  3) 

(m)  Defense  Standardization  Manual  9120. 3M,  "Standardization  Policies, 

Procedures  and  Instructions,"  January  19f2 


#First  amendment  (Ch  1,  12/28/76) 


NUMBER  5 1- 00.  31 

DATE  Xovembcr  24,  1  '7o 


ASD(UL)/DDRiE/DTACCS/ASD(C) 

Department  of  Defense  Instruction 


SUBJECT  :  Interim  List  of  DoD  Approved  High  Order  Programming  Languages  (HOI.) 


References:  (a)  DoD  Directive  5000.29,  "Management  of  Computer  Resources 

in  Major  Defense  Systems,"  April  2b,  1976 

(b)  DoD  Directive  5000.1,  "Acquisition  of  Major  Defense 

Systems,"  December  22,  1975 

(c)  DoD  Directive  5100.40,  "Responsibility  for  the  Adminis¬ 

tration  of  the  DoD  Automatic  Data  Processing  Program," 
August  19,  1975 


i .  PURPOSE 


This  Instruction  specifies  the  High  Order  Programming  Languages  (HOL) 

which  are  approved  for  use  in  conjunction  with  reference  (a). 

II .  APPLICABILITY  AND  SCOPE 

A.  The  provisions  of  this  Instruction  apply  to  the  Office  of  the 
Secretary  of  Defense,  the  Military  Departments,  the  Organization 
of  the  Joint  Chiefs  of  Staff,  and  the  Defense  Agencies  (herein¬ 
after  referred  to  collectively  as  "DoD  Components"). 

B.  Its  provisions  encompass  the  selection  of  HOL  for  the  develop¬ 
ment  of  software  in  major  programs  of  defense  systems  acquisition 
as  designated  by  the  Secretary  of  Defense  (described  in  section  II 
of  reference  (b)),  as  well  as  for  defense  system  acquisitions  that 
do  not  fall  in  the  "major  acquisition"  category. 

C.  Excluded  from  the  provisions  of  this  Instruction  are: 

1.  Commercially  available  software  for  use  with  automatic  data 
processing  assets  as  defined  and  administered  under  reference 
(c). 

2.  Those  application  or  user  oriented  languages  which  do  not  fall 
within  the  category  of  a  programming  language  (e.g.,  User 
Requirements  Languages,  Automatic  Test  Equipment  Languages, 
Production  Control  Languages,  simulation  Languages,  and  Analyst 
Aid  Languages) . 

D.  The  provisions  of  the  Instruction  are  not  to  be  applied  retro¬ 
actively  on  any  defense  systems  where  a  language  commitment  has 
already  been  made,  nor  is  it  to  be  interpreted  as  prejudicial  to 
language  selections  occurring  before  DoD  policy  formulation. 
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DEFINITION 


For  purposes  of  this  Instruction  a  HOL  is  one  which  provides  com¬ 
pression  of  computer  instructions  such  that  one  HOL  statement 
represents  many  machine  language  instructions.  It  is  non-problem- 
specific  and  is  used  by  programmers  to  communicate  with  a  computer 

POLICY 

A.  General 

1.  This  Instruction  and  DoD  Directive  5000.29  (reference  (a)) 
is  designed  to  reduce  the  proliferation  of  HOL  in  defense 
systems  and  to  ensure  control  of  those  HOLs  which  are 
approved . 

2.  DoD  approved  HOLs  will  be  used  to  develop  defense  system 
software,  unless  it  is  demonstrated  that  none  of  the 
approved  HOLs  are  cost  effective  or  technically  practical 
over  the  system  life  cycle  (reference  (a),  subsection 
V.G.).  Each  DoD  Component  will  designate  in  its  instruc¬ 
tion  implementing  DoD  Directive  5000.29  (reference  (a)) 
one  office  authorized  to  approve  requests  for  such  excep¬ 
tions.  The  designated  approval  authority  will  maintain 
appropriate  records  to  support  periodic  review  by  the 
Management  Steering  Committee  for  Embedded  Computer 
Resources . 

3.  Each  DoD  approved  HOL  will  be  assigned  to  a  designated 
control  agent  who  will  be  responsible  for  such  activities 
as  assuring  language  stability  and  configuration  manage¬ 
ment,  validating  compliance  of  compiler  implementations 
with  the  standard  language  specifications,  gathering  data 
as  to  the  use  of  the  languages,  and  for  disseminating 
information,  compilers,  and  tools  (reference  (a)  subsec¬ 
tion  V.G. ) . 

B.  Approved  High  Order  Programming  Languages 

The  DoD  approved  High  Order  Programming  Languages,  and 
their  defining  specification  documents  are: 


CMS-2  "CMS-2Y  Programmers  Reference  Manual," 
M-5049 ,  FDCSSA ,  San  Diego,  CA. , 
October  1,  1976;  and  "CMS-2M  Computer 
Program  Performance  Specifications," 
NAVELEX  0967LP- 59 8-2210. 


5000.  31 
Nov  24, 


b.  SPL-1  "SPL-1  Language  Reference  Manual,"  Intermetrics 

Report  No.  172-1. 

c.  TACPOL  CPCEI  Part  I  Specification  EL-CC-0004 3082C 

Volume  1,  April  16,  1971  with  ECO  Modifica¬ 
tions  (Appendix  10) , 

d.  JOVIAL  Military  Standard  (MIL-STD)  1588  (USAF)  for 

J3  and  MIL-STD-1589  (USAF)  for  J73. 

e.  COBOL  ANSI  X3.23  -  1974. 

f.  FORTRAN  ANSI  X3.9  -  1974. 

2.  The  languages  CMS-2  and  SPL-1  shall  be  controlled  within 
DoD  by  the  Department  of  the  Navy. 

3.  The  language  TACPOL  shall  be  controlled  by  the  Department 
of  the  Army. 

4.  The  language  JOVIAL  shall  be  controlled  by  the  Department 
of  the  Air  Force. 

5.  The  languages  COBOL  and  FORTRAN  shall  be  controlled  by  the 
Office  of  the  Assistant  Secretary  of  Defense  (Comptroller) 
acting  with  the  National  Bureau  of  Standards  and  the 
American  National  Standards  Institute  (DoD  Directive  5100.40, 
reference  (c)). 

RESPONSIBILITIES 

A.  The  Management  Steering  Committee  for  Embedded  Computer 
Resources,  DoD  Directive  5000.29  (reference  (a)),  shall  oversee 
and  coordinate  the  accomplishment  of  the  policies  in  this 
Instruction,  and  advise  the  principal  assistants  of  the  Office 
of  the  Secretary  of  Defense  on  matters  related  to  this  policy. 

B.  The  Military  Departments  will  designate  control  agents  for 
each  H0L  under  their  purview. 

C.  The  H0L  control  agents  so  designated  by  the  Military  Depart¬ 
ments  are  authorized  to  update  their  designated  language  with 
compatible  extensions  and  improvements  to  satisfy  validated 
requirements.  Such  extensions  (e.g.  new  syntax  and/or  new 


semantics)  should  not  be  made  more  often  than  once  per  vear. 
The  COBOL  and  FORTRAN  control  agents  must  comply  with  the  cur¬ 
rent  approved  version  of  the  American  National  Standards 
Institute . 


VI.  EFFECTIVE  DATE 


This  Instruction  is  effective  immediately. 


Assistant  Secret^ny  of  Defense 
(installations  ana  Logistics) 


Assistant  Secretary  of  Defense 
jS  Comptroller)/ 


Director  Telecommunications  and 
Command  and  Control  Systems 


Director  of  Defense  Research  and 
Engineering 


v.v.v.v 


vs  s 


DEPARTMENT  OF  THE  AIR  FORCE  AF  REGULATION  800-14 

Headquarters  US  Air  Force  Volume  I 

Washington  DC  20330  12  September  1 975 


Acquisition  Management 

MANAGEMENT  OF  COMPUTER  RESOURCES  IN  SYSTEMS 

Volume  I  establishes  policy  for  the  acquisition  and  support  of  computer  equipment  and  computer  programs  em¬ 
ployed  as  dedicated  elements,  subsystems  or  components  of  systems  developed  or  acquired  under  the  program 
management  concept  established  in  AFR  800-2.  Other  computer  resources  will  be  acquired  and  managed  in  ac¬ 
cordance  with  applicable  regulations. 
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Objective  of  This  Regulation  .  t .  2 

Air  Force  Policy  on  Management  of  Computer  Resources  in  Systems .  3 

Section  B — Assigned  Responsibilities 

Headquarters  USA F .  4 

Air  Force  Systems  Command  (A  FSC) .  5 

Program  Manager .  6 

Air  Force  Logistics  Command  (AFLC) .  7 

Using  Activities  .  8 

Air  Training  Command  (ATC) .  9 

Air  University .  10 

Attachments  Page 

1.  Terms  Explained  .  5 

2.  Applicability  of  Air  Force  Regulations  Pertaining  to  AD?  and  Computer  Resources .  6 


SECTION  A— GENERAL  INFORMATION 

1.  Applicability  of  This  Regulation.  This  regulation 
applies  to  all  Air  Force  activities  responsible  for 
planning,  developing,  acquiring,  supporting  and  using 
systems  managed  or  acquired  under  AFR  800-2. 

2.  Objective  of  This  Regulation.  The  objective  of  this 
regulation  is  to  insure  that  computer  resources  in 
systems  are  planned,  developed,  acquired,  employed, 
and  supported  to  effectively,  efficiently,  and 
economically  accomplish  Air  Force  assigned  missions. 

3.  Air  Force  Policy  on  Management  of  Computer 
Resources  in  Systems: 


production,  employment,  operation  and  support 
phases.  System  performance  requirements  are 
allocated  to  subsystems  using  in-depth  trade-off 
studies  and  cost-effectiveness  analyses. 

b.  Management  responsibility  for  the  integration  of 
computer  equipment  and  computer  programs  into  a 
system  remains  centralized  for  the  life  of  the  system. 
Responsibility  for  the  computer  equipment  and 
computer  programs  will  transfer  in  accordance  with 
AFR  800-4  and  turnover  in  accordance  with  AFR 
800-19.  Responsibility  for  development  maintenance 
and  modification  of  selected  computer  programs  may 
be  assigned  commensurate  with  operational  and 
support  requirements. 


a.  Computer  resources  in  systems  are  managed  as 
elements  or  subsystems  of  major  importance  during 
conceptual,  validation,  full-scale  development. 

Supersedes  AFR  800-14,  10  May  1974.  (For  summary 
of  revised,  deleted,  or  added  material,  see  signature 
page.) 

OPR:  RDM 

DISTRIBUTION:  F;  X; (Defer  e  Systems  Manage- 
ment  School  Ft  Belvoir  VA  2006C  .  100) 


c.  Organic  computer  equipment  maintenance  and 
computer  program  development  and  maintenance 
capabilities  are  established  where  economical  or  to 
satisfy  system  requirements.  Common  and  existing 
capabilities  are  used  wherever  practicable. 

d.  Computer  equipment  and  computer  programs 
are  standardized  to  the  extent  practicable  within  each 
system  as  well  as  across  systems.  Common  purpose 
automatic  test  equipment  is  desirable. 


e.  Automatic  data  processing  ( ADP)  standards  and 


AFR  800-14  Volumel  12 September  1975 


higher  level  programming  languages  are  used  to  the 
maximum  extent  practicable  in  the  system  under 
development. 

f.  Computer  equipment  and  computer  program 
trade-offs  are  conducted  throughout  the  life  cycle  of 
the  system  to  minimize  cost  and  insure  growth 
capability  consistent  with  operational  requirements. 

g.  Organizational  responsibilities  and  computer 
resource  requirements,  including  support  facilities, 
personnel,  documentation,  training  and  other  essential 
resources  are  identified  early  in  the  system 
development  program  to  insure  coordinated  actions 
and  integrated  support  for  the  system  life  cycle. 

h.  Da. a  item  descriptions  are  identified  and 
developed  as  required  to  insure  timely  and  adequate 
program  documentation  support  throughout  the 
system  life  cycle. 

i.  Solicitation  documents  include  explicit 
statements  establishing  Air  Force  rights  to  computer 
programs  required  to  operate,  simulate  and  support 
the  system.  This  includes  computer  programs  and 
associated  documentation  required  for  the 
maintenance  and  modification  of  these  programs. 

j.  Configuration  management  procedures  are 
developed  to  assure  control  during  development,  test, 
transfer  and  turnover,  operational  maintenance,  and 
major  modification. 

k.  An  inventory  of  computer  equipment  and 
computer  programs  is  developed  and  maintained. 

l.  User  involvement  is  an  integral  part  of  computer 
program  development,  test,  operational  maintenance 
and  major  modification.  The  scope  and  degree  of 
involvement  is  determined  by  system  and  operational 
requirements. 

m.  Program  Management  Directives  (PMDs) 
require  and  Program  Management  Plans  (PMPs) 
provide  for: 

(1)  Establishment  of  computer  technical  and 
managerial  expertise  responsive  to  the  Program 
Office  (PO)  which  is  independent  of  the  system  prime 
or  computer  program  development  contractor  and, 
preferably,  an  organic  capability  of  the  PO. 

(2)  The  specification  and  allocation  of  system 
performance  and  interface  requirements  to  be  met  by 
computer  equipment  and  computer  programs. 

(3)  Reliability,  maintainability,  and  availability 
as  prime  development  objectives. 

(4)  Sufficient  computer  equipment  capacity  and 


flexible  computer  program  design  during  the  planning 
and  development  phases  to  provide  for  planned 
growth  and  ease  of  modification  and  maintenance 
throughout  the  system  life 

(5)  The  timely  preparation  of  support  plans  for 
development,  acquisition,  life  cycle  operational 
maintenance  and  training  for  computer  equipment, 
computer  programs,  supporting  documentation  and 
facilities. 

(6)  The  level  of  simulation  to  be  employed  to 
assist  and  assure  the  acquisition  of  systems  responsive 
to  mission  requirements  and  to  minimize  the  cost  or 
risk  associated  with  changes  throughout  the  system 
lifecycle. 

(7)  The  comprehensive  test  of  computer 
equipment  and  verification  and  validation  of 
computer  programs.  Special  emphasis  is  directed  to 
these  items  during  the  testing  and  evaluation 
conducted  in  accordance  with  AFR  80-14. 

(8)  The  identification  of  computer  equipment 
and  computer  programs  as  configuration  items  (CIs). 

(9)  Work  breakdown  structures  (MIL  STD-881) 
designed  to  facilitate  identification  of  computer 
resource  costs. 

(10)  Coverage  of  computer  equipment  and 
computer  programs  during  the  conduct  of  system 
design  reviews,  audits  and  management  assessments. 

SECTION  B— ASSIGNED  RESPONSIBILITIES 

4.  Headquarters  USAF: 

a.  Provides  for  the  management  of  computer 
resources  in  systems  consistent  with  the  policies  in  this 
and  other  applicable  regulations. 

b.  Insures  that  policies  and  procedures  for  the 
management  of  computer  equipment  and  computer 
programs  are  consistent  with  other  applicable  policies, 
regulations  and  directives. 

5.  Air  Force  Systems  Command  ( AFSC): 

a.  Provides  for  the  implementation  of  this 
regulation  in  the  development,  acquisition,  transfer 
and  turnover  of  assigned  systems  involving  computer 
resources. 

b.  Maintains  an  organic  capability  of  computer 
technical  and  managerial  expertise  as  necessary  to 
support  assigned  responsibilities. 

c.  Provides  for  the  standardization  of  computer 
equipment  and  computer  programs  between  and 
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within  systems  and  insures  optimum  usage  of 
available  computer  resources  as  practicable 

d.  Insures  the  timely  application  of  advanced 
computer  technology  into  systems 

e.  Develops  jointly  with  AFLC  an  inventory  and 
data  base  on  computer  equipment  and  computer 
programs  used  in  systems.  Provides  update 
information  to  AFLC  as  new  systems  are  developed 

f.  Satisfies  oRier  responsibilities  as  defined  in  the 
Air  Force  800  series  and  other  applicable  regulations. 

6.  Program  Manager: 

a.  Provides  management  and  technical  emphasis  to 
computer  equipment  and  computer  program 
requirements  identified  in  the  PMD 

b.  Directs  the  preparation,  update  and 
implementation  of  the  PMP  consistent  with  the 
policies  of  this  regulation. 

c.  Insures  that  the  PO  works  with  AFLC  and  the 
user  to  incorporate  their  needs  into  the  PMP, 
supporting  plans  and  other  system  documents 
prepared  and  implemented  by  the  PO 

d.  Satisfies  other  responsibilities  as  defined  in  the 
Air  Force  800  series  and  other  applicable  regulations 

7.  Air  Force  Logistics  Command  (AFLC): 

a.  Provides  for  the  implementation  of  this 
regulation  during  the  transfer  and  support  of  systems 
involving  computer  resources. 

b.  Maintains  an  organic  capability  of  computer 
technical  and  managerial  expertise  as  necessary  to 
support  assigned  responsibilities. 


determined  necessary  to  support  AFLC  assigned 
responsibilities  for  the  integration  and  maintenance  of 
the  total  system.  Uses  common  and  existing  facilities 
wherever  practicable 

g.  Insures  the  standardization  of  computer 
equipment  and  computer  program  support  facilities 
and  equipment  wherever  practicable 

h.  Satisfies  other  responsibilities  as  defined  in  the 
Air  Force  800  series  and  other  applicable  regulations. 


8.  Using  Activities: 

a.  Provide  for  the  implementation  of  this 
regulation  in  the  turnover,  operation  and  maintenance 
of  systems  involving  computer  resources. 

b.  Assure  continuing  involvement  with  the  PO  and 
AFLC  >n  the  development,  test,  transfer,  turnover  and 
operation  of  computer  equipment  and  computer  pro¬ 
grams  in  systems. 

c.  Maintain  an  organic  capability  of  computer 
technical  and  managerial  expertise  as  necessary  to 
support  assigned  responsibilities. 

d.  Participate  with  the  PO  and  AFLC  in  the 
preparation,  update  and  implementation  of  the  PMP, 
support  plans  and  other  system  documents  Insure 
accurate  incorporation  and  timely  update,  within  the 
approved  program,  of  mission  requirements 

e.  Participate  with  the  PO  and  AFLC  in 
determining  responsibilities  for  the  maintenance  and 
modification  of  computer  equipment  and  modifica¬ 
tions  to  computer  programs  for  incorporation  into 
system  documents. 

f.  Program  for.  establish  and  operate  facilities 
determined  necessary  to  support  assigned 
responsibilities  for  the  maintenance,  modification  and 
development  of  computer  programs. 


c.  Develops  jointly  with  AFSC  and  maintains  an  g  Satisfy  other  responsibilities  as  defined  in  the  Air 
inventory  and  data  base  on  computer  equipment  and  Force  800  series  and  other  applicable  regulations, 

computer  programs  in  systems 


d.  Participates  with  the  PO  and  the  user  in  the 
preparation,  update  and  implementation  of  the  PMP. 
support  plans  (including  the  integrated  logistics 
support  plan)  and  other  system  documents. 

e.  Participates  with  the  PO  and  the  users  in 
determining  responsibilities  for  the  maintenance  and 
modification  of  computer  equipment  and  computer 
orograms  for  incorporation  into  system  documents 

f.  Programs  for,  establishes  and  operates  facilities 


9.  Air  Training  Command  (ATC): 

a  Reviews  system  documents  and  initiates  training 
support  planning. 

b.  Provides  and  administers  training  programs  to 
support  systems  in  accordance  with  AI  R  50-9. 


10.  Air  University  Provides  professional  education  in 
computer  sciences  and  management  in  accordance 
with  AFR  55- 1 1  and  AFM  50-5 
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BY  THE  ORDER  OF  THE  SECRETARY  OF  THE  AIR  FORCE 
OFFICIAL 


DAVID  C.  JONES,  General,  USAF 
Chief  of  Staff 


JAMES  J.  SHEPARD.  Colonel,  USAF 
Director  of  Administration 


SUMMARY  OF  REVISED,  DELETED,  OR  ADDED  MATERIAL 

This  revision  renumbers  AFR  800-14  to  AFR  800-14,  Volume  I;  and  updates  the  terms  “transition  and  turnover” 
to  “transfer  and  turnover”  in  accordance  with  AFRs  800-4  and  800-19. 
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TERMS  EXPLAINED 


1.  Availability.  A  measure  of  the  degree  to  which  an 
item  is  in  the  operable  and  committable  state  at  the  start 
of  the  mission,  when  the  mission  is  called  for  at  an 
unknown  (random)  point  in  time.  (MlL-STD-721) 

2.  Computer  Program.  A  series  of  instructions  or  state¬ 
ments  in  a  form  acceptable  to  an  electronic  computer, 
designed  to  cause  the  computer  to  execute  an  operation 
or  operations. 

3.  Computer  Resources.  The  totality  of  computer 
equipment,  computer  programs,  associated  document¬ 
ation,  contractual  services,  personnel  and  supplies. 

4.  Configuration  Item  (Cl).  An  aggregation  of  equip¬ 
ment/software,  or  any  of  its  discrete  portions,  which 
satisfies  an  end  use  function  and  is  designated  by  the 
Government  for  configuration  management  Cls  may 
vary  widely  in  complexity,  size  and  type,  from  an 
aircraft  or  electronic  system  to  a  test  meter  or  round  of 
ammunition.  During  development  and  initial  production, 
Cls  are  only  those  specification  items  that  are  referenced 
directly  in  a  contract  (or  an  equivalent  in-house  agree¬ 
ment).  During  the  operation  and  maintenance  period, 
any  reparable  item  designated  for  separate  procurement 
is  a  configuration  item.  (AFR  65-3) 

$.  Data  Item  Description,  DD  Form  1664.  A  form 
which  specifies  an  item  of  data  required  to  be  furnished 
by  a  contractor.  This  form  specifically  defines  the 
content,  preparation  instructions,  format  and  intended 
use  of  each  data  product.  (AFR  310-1) 

6.  Higher  Level  Programming  Languages.  Primarily, 
machine  independent  programming  languages  (of  a 
higher  order  than  assembly  languages)  designed  for  ease 
of  expression  of  a  class  of  problems  or  procedures  by 
humans.  These  languages  are  designed  for  convenience  of 
program  specification  rather  than  for  easy  conversion  to 
machine  code  instruction.  The  languages  are  intended: 

a.  As  a  means  for  directly  presenting  procedures  to  a 
computer  for  which  a  compiler  exists;  and 

b.  As  a  means  of  communicating  such  procedures 
among  individuals.  (AFR  300-10) 

7.  Program  Manager.  The  generic  term  used  to  denote  a 
single  Air  Force  manager  (System  Program  Director, 


Program/Project  Manager,  or  System/Item  Manager) 
during  any  specific  phase  of  the  acquisition  life  cycle. 
(AFR  800-2) 

8.  Program  Management  Directive  (PMD).  The  official 
HQ  USAF  management  directive  used  to  provide  direc¬ 
tion  to  the  implementing  and  participating  commands 
and  satisfy  documentation  requirements.  It  will  be  used 
during  the  entire  acquisition  cycle  to  state  requirements 
and  request  studies  as  well  as  initiate,  approve,  change, 
transition,  modify  or  terminate  programs.  The  content 
of  the  PMD,  including  the  required  HQ  USAF  review 
and  approval  actions,  is  tailored  to  the  needs  of  each 
individual  program.  (AFR  800-2) 

9.  Program  Management  Plan  (PMP).  The  document 
developed  and  issued  by  the  Program  Manager  which 
shows  the  integrated  time-phased  tasks  and  resources 
required  to  complete  the  task  specified  in  the  PMD.  The 
PMP  is  tailored  to  the  needs  of  each  individual  program. 
(AFR  800-2) 

10.  Program  Office  (PO).  The  field  office  organized  by 
the  Program  Manager  to  assist  him  in  accomplishing  the 
program  tasks.  (AFR  800-2) 

11.  Simulation.  The  representation  of  physical  systems 
or  phenomena  by  computers,  models  or  other  equip¬ 
ment. 

12.  Tranafcr.  That  point  in  time  when  the  designated 
Supporting  Command  accepts  program  management 
responsibilities  from  the  Implementing  Command.  This 
includes  logistic  support  and  related  engineering  and 
procurement  responsibilities.  (AFR  800-4) 

13.  Turnover.  That  point  in  time  when  the  operat¬ 
ing  command  formally  accepts  responsibility  from  the 
Implementing  Command  for  the  operation  and  main¬ 
tenance  of  the  system,  equipment,  or  computer  program 
acquired  (AFft  800-19). 

14.  Verification/Validation  (of  computer  programs). 
The  process  of  determining  that  the  computer  program 
was  developed  in  accordance  with  the  stated  specifi¬ 
cation  and  satisfactorily  performs,  in  the  mission  envi¬ 
ronment,  the  functidn(s)  for  which  it  was  designed. 
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Chapter  1 
INTRODUCTION 


1-1.  Scope.  The  uniqueness  of  computer  re¬ 
source  management  requires  the  publication 
of  a  document  which  consolidates  and  exp¬ 
lains  the  applicability  of  other  publications  to 
computer  resource  acquisition  and  support. 
This  volume  of  AFR  800-14  serves  that  pur¬ 
pose  by  restating  applicable  portions  of  re¬ 
lated  publications  identified  in  attachment  2 
and  amplifies  the  policies  of  those  publica¬ 
tions.  It  is  intended  to  ensuie  that  specific 
attention  to  the  management  of  computer  re¬ 
sources  is  accomplished  within  the  context  of 
the  overall  system  program  technical  and 
management  efforts.  It  must  be  used  with 
any  other  publication  in  attachment  2  that 
applies.  Offices  responsible  for  policy  in  those 
publications  remain  responsible  for  policy  in 
the  functional  areas,  for  example,  HQ 
USAF/LG  will  establish  and  interpret  all  pol¬ 
icy  related  to  procurement  and  configuration 
management.  Conflicts  between  this  publica¬ 
tion  and  the  referenced  publications  will  im¬ 
mediately  be  called  to  the  attention  of  HQ 
USAF/RDM  with  an  information  copy  to  the 
functional  office  responsible  for  the  other 
publication. 

1-2.  Applicability.  The  procedures  prescribed 
in  this  volume  are  tailored  to  the  needs  of  the 
program  or  project.  Changes  to  existing  sys¬ 
tems,  including  deployed  systems,  will  be  re¬ 
viewed  on  a  case-by-case  basis  to  determine 
their  application  to  this  regulation.  This  de¬ 
termination  will  be  made  by  the  command  or 
agency  having  final  approval  authority  for 
the  change  in  coordination  with  implement¬ 
ing,  supporting  and  using  commands.  Com¬ 
mands  may  supplement  this  regulation.  One 
copy  of  each  command  supplement  will  he 
forwarded  to  HQ  USAF/RDM. 

1-3.  Glossary.  See  attachment  I. 


1-4.  Bibliography.  See  attachment  2  for  a 
compilation  of  referenced  documents. 

1-5.  Air  Force  Working  Group.  A  working 
group  will  be  established  to  review  the  im¬ 
plementation  of  this  regulation.  The  execu¬ 
tive  agent  of  the  working  group  will  be  HQ 
USAF/RDM  and  membership  will  consist  of 
representatives  from  HQ  USAF,  Air  Force 


Systems  Command  (AFSC),  Air  Force  Logis¬ 
tics  Command  (AFLC),  and  appropriate  using 
commands.  The  group  will  meet  ti  months 
after  the  publication  date  of  this  regulation 
and  annually  thereafter  to  recommend 
changes  and  incorporate  new  developments. 

1-6.  Interface  With  AFR  300-1,  Automatic 
Data  Processing  Program  Management.  Au¬ 
tomatic  data  processing  (A DP)  resources  in 
systems  acquired  under  AFR  800-2  are  sub¬ 
ject  to  the  policies  of  AFR  300-1  as  well  as 
AFR  800-14.  The  policies  of  AFR  300-1  apply 
in  the  sense  that  the  program  manager  is 
encouraged  to  seek  technical  and  managerial 
expertise  from  the  A  DP  Single  Manager  or¬ 
ganization.  These  organizations  will  provide, 
upon  request,  reviews,  consultation  and  re¬ 
commendations. 

1-7.  Interface  With  AFR  300-2,  Management 
of  Automatic  Data  Processing  Systems.  ADP 

resources,  in  systems  acquired  under  AFR 
800-2,  are  subject  to  the  policies  of  AFR  300-2 
to  the  extent  specified  by  the  program  man¬ 
agement  directive  (PMD).  If  the  PMD  does 
not  require  AFR  300-2  procedures,  then  the 
program  manager  will  follow  the  provisions  of 
AFR  800-14  and  will  exercise  identical  au¬ 
thority  in  the  acquisition  of  system  computer 
resources  and  other  system  components. 

1-8.  Supporting/Using  Command  Roles.  The 

supporting  and  using  commands  will  actively 
participate  in  all  phases  of  acquisition.  Par¬ 
ticipation  includes,  but  is  not  limited  to:  re¬ 
quirements  definition,  specification  develop¬ 
ment,  source  selection,  design  reviews,  au¬ 
dits.  validat  ion  verification  (of  computer 
programs),  testing,  and  acceptance. 

1-9.  Implementation.  At  the  time  of  publish¬ 
ing  this  volume  several  exsiting  .publications 
will  require  change  to  provide  for  the  conceP* 
set  fort  h  herein.  For  example:  AFR  800-14,  10 
May  1974,  will  be  renumbered  as  volume  I; 
AFR  57-4  and  TO  00-35P-54  require  expan¬ 
sion  to  provide  more  detailed  guidance  tor 
computer  resources;  and  A  h  R  8-2  and  TO 
00-5-1  require  change  to  delete  computer 
programs  from  the  technical  order  system. 
Further,  some  major  command  actions  are 
necessary,  such  as:  the  development  of  a 
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numbering  system  for  computer  programs  by 
AFLC  in  conjunction  with  AFSC,  and  de¬ 
velopment  of  configuration  status  accounting 
procedures  to  include  computer  resources 
into  existing  management  systems  as  config¬ 
uration  items.  All  such  actions  will  be  expe¬ 


dited  to  assure  policy  consistency.  Managers 
should  recognize  that  the  changes  are  in  pro¬ 
cess  and  initiate  management  actions  in  ac¬ 
cordance  with  the  provisions  of  this  regula¬ 
tion. 
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Chapter  2 

COMPUTER  RESOURCES  IN  THE  SYSTEM  ACQUISITION  LIFE  CYCLE 


2-1.  Purpose.  This  chapter  discusses  compu¬ 
ter  resources  in  the  system  acquisition  life 
cycle,  defines  the  computer  program  life  cycle 
and  discusses  the  relationship  of  the  two  cy¬ 
cles. 

2-2.  System  Acquisition  Life  Cycle.  The  sys¬ 
tem  acquisition  life  cycle  provides  a  hasis  for 
categorizing  program  management  activities. 
It  consists  of  five  major  phases  with  major 
decision  points  as  defined  .a  AFR  800-2. 
Programs  may  slip  a  phase  or  have  program 
elements  in  any  or  all  phases.  The  following 
description  explains  a  normal  system  acquisi¬ 
tion  with  emphasis  on  computer  resources. 

2-3.  Conceptual  Phase.  This  is  the  initial 
planning  period  when  the  technical,  military 
and  econoriic  bases  are  established  through 
comprehensive  studies,  experimental  de¬ 
velopment  and  concept  evaluation.  The  objec¬ 
tive  of  thi  :  initial  planning  may  be  directed 
toward  refining  proposed  solutions  or  de¬ 
veloping  alternative  concepts  to  satisfy  a  re¬ 
quired  operational  capability. 

a.  During  this  phase,  proposed  solutions 
are  refined  or  alternative  concepts  are  de¬ 
veloped  using  feasibility  assessments,  esti¬ 
mates  (cost  and  schedule,  intelligence,  logis¬ 
tics,  and  so  forth),  tradeoffs,  studies,  and 
analyses  (chapter  3). 

b.  The  major  definitive  document  resulting 
from  this  phase  is  the  initial  system  specifica¬ 
tion  which  documents  total  system  perfor¬ 
mance  requirements.  It  may  document  the 
requirements  to  be  met  by  computer  re¬ 
sources  as  well  as  relevant  design  con¬ 
straints.  An  adequate  definition  of  essential 
system  interfaces  between  computer  equip¬ 
ment  functions,  communication  functions, 
and  personnel  functions  should  be  provided  to 
enable  the  further  definition  and  manage¬ 
ment  of  the  computer  programs  and  computer 
equipment  into  configuration  items.  Nor¬ 
mally,  this  information  is  derived  from  sys¬ 
tem  engineering  studies  of  the  system  func¬ 
tions. 

2-4.  Validation  Phase.  This  is  the  period 
when  major  system  characteristics  are  re¬ 
fined  through  studies,  system  engineering, 
and  preliminary  equipment  and  computer 
program  development,  test  and  evaluation. 
The  objective  is  to  validate  the  choice  of  al¬ 
ternatives  and  to  provide  the  basis  for  deter¬ 


mining  whether  or  not  to  proceed  into  the 
next  phase. 

a.  During  this  period,  system  performance 
requirements  including  computer  resources 
are  further  defined  and  preferred  develop¬ 
ment  methodologies  for  computer  programs, 
such  as  organic  or  contractor,  per  AFR  26-12, 
are  selected.  Validation  phase  activities  de¬ 
fine  the  efforts  required  by  characteristics 
(performance,  cost  and  schedule)  and  provide 
confidence  that  risks  have  been  resolved  or 
minimized.  Technical  reviews  that  should  be 
accomplished  are  the  System  Requirements 
Review! si  and  System  Design  Review  (chap¬ 
ter  4). 

b.  For  computer  resources,  the  major  de¬ 
finitive  documents  resulting  from  this  phase 
are  the  authenticated  system  specification, 
the  preliminary  development  specifications 
containing  system  functional  requirements 
allocated  to  configuration  items  of  computer 
programs  and  equipment,  and  the  initial 
computer  resources  integrated  support  plan 
(CRISP).  The  initial  preparation  and  coordi¬ 
nation  of  the  CRISP  (chapter  3)  is  ac¬ 
complished  as  soon  as  possible  to  permit  the 
program  manager  to  accommodate  approp¬ 
riate  CRISP  provisions  in  the  full-scale  de¬ 
velopment  contracts. 

2-5.  Full-Scale  Development  Phase.  This  is 
the  period  when  the  system,  equipment,  com¬ 
puter  programs,  facilities,  personnel  subsys¬ 
tems,  training,  and  the  principal  items  neces¬ 
sary  for  support  are  designed,  fabricated, 
tested,  and  evaluated.  The  intended  outputs 
are  a  system  which  closely  approximates  the 
production  item,  the  documentation  neces¬ 
sary  to  enter  the  production  phase,  and  the 
test  results  which  demonstrate  that  the  sys¬ 
tem  to  be  produced  will  meet  the  stated  per¬ 
formance  requirements. 

a.  The  development  specifications  are  com¬ 
pleted  and  authenticated.  Authentication  of 
any  development  specification  establishes  the 
allocated  baseline.  A  preliminary  design  ef¬ 
fort  is  accomplished  leading  to  an  acceptable 
design  approach.  A  preliminary  design  review 
(PDR)  is  held  for  each  equipment  configura¬ 
tion  item  and  computer  program  configura¬ 
tion  item  (CPCI)  to  review  the  preliminary 
design  against  the  respective  authenticated 
development  specification  (chapter  4).  Formal 
engineering  change  control  procedures  are 
implemented  to  prepare,  propose,  review,  ap- 
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prove,  implement,  ami  record  engineering 
change'  to  the  allocateil  baseline  (chapter  6). 
For  computer  programs,  the  preliminary  de¬ 
sign  lncluiies  the  definition  of  t  he  eiit  l  re  com¬ 
puter  program  in  terms  of  fu  net  ions,  external 
and  internal  interfaces,  storage  allocation, 
computer  program  operating;  sequences,  and 
the  design  of  the  data  base.  This  information 
should  he  contained  in  the  development 
specifications  and  become  the  basis  for  tin* 
IM>R  of  the  computer  prop-ram 

h.  Following  an  acceptable  1‘DR  for  a  con¬ 
figuration  item,  detailed  desipn  of  that  item 
bepins.  This  activity  produces  elipt  iieeli  up 
document  at  urn  such  as  drawmps,  product 
s peci fical ions  and  test  plans.  For  computer 
proprams,  desipn  is  ttecompanied  by 
documentation  of  topical  Hows,  functional 
sequences  and  relations.  formats,  con¬ 
straints,  and  the  data  base  'Hus  documenta¬ 
tion  should  he  reviewed  by  Air  Force  en- 
pineerinp  personnel  prior  to  the  critical  de¬ 
sign  review  t('DR).  The  < ' I  > R  should  assure 
that  the  recommended  desipn  satisfies  the 
requirements  of  the  development  specifica¬ 
tion.  At  the  CDK,  specified  portions  of  draft 
Product  Specifications  are  reviewed. 
Equipment  personnel  computer  propram  in¬ 
terfaces  should  be  finalized  at  this  time.  A 
Computer  Propram  Identification  Number 
(('PIN)  should  be  assipned  to  all  CPCIs  and 
related  documents  prior  to  <’[)R  (chapter  <’>). 
The  primary  product  of  the  <T)R  for  CPCIs  is 
the  identification  ot  specific  portions  of  the 
Product  Specification  which  will  be  released 
for  codinp  and  testinp. 

c.  Development,  test  and  evaluation 
(DT&H)  and  initial  operational  test  and 
evaluation  (IOT&E)  are  conducted  (chapter 
5).  Testinp  of  confipuration  items  is  per¬ 
formed  accordinp  to  formal  test  plans  initially 
submitted  in  preliminary  draft  form  for  re¬ 
view  at  CDR,  and  finalized  prior  to  the  start 
of  testinp.  These  activities  normally  proceed 
in  such  a  way  that  testinp  of  selected  func¬ 
tions  bepins  early  durinp  development  and 
proceeds  thi'ouph  successively  detailed  levels 
of  assembly  to  the  point  where  the  complete 
computer  propram  is  subjected  to  formal 
qualification  testinp.  Additional  computer 
proprams  and  equipment  may  be  required  to 
properly  simulate  the  operational  environ¬ 
ment  or  to  test  the  computer  proprams.  The 
s-. . * . •  ■  I  realism  of  computer  propram  test¬ 
inp  may  be  propressively  expanded  as  addi¬ 
tional  items  of  the  operational  computer 
equipment,  are  made  available  for  this  pur¬ 
pose.  Adequacy  of  the  performance  of  the 
computer  proprams  is  checked  to  the 


maximum  extent  possible  throuph  prudent 
use  of  simulation  prior  to  the  installation  of 
the  computer  propram  in  a  field  site  or  flipht 
computer.  The  use  of  artificial  data  or  re¬ 
corded  data  from  similar  equipment  should  he 
considered.  Nuclear  safety  cross-check 
analysis  i.NSCCA)  is  also  performed  on 
specified  computer  resource  items  (AFR 
122  -1).  Satisfactory  performance  of  the  com¬ 
puter  propram  for  a  larpe  operational  system 
may  not  he  completely  demonstrated  and  as¬ 
sessed  until  completion  of  operational  test 
and  evaluation  (OT&F. ).  For  less  complex 
computer  proprams,  or  for  computer  prop¬ 
rams  which  are  relatively  insensitive  to  the 
system  operational  function.-,  formal  qualifi¬ 
cation  testinp  may  he  accomplished  earlier  in 
tin*  acquisition  (chapter  5). 

d.  I'lanninp  for  transfer  of  the  system  to 
the  supportinp  command  and  turnover  to  the 
usinp  command  bepins  early  in  this  period. 
Necessary  apreements  should  he  prepared, 
coordinated,  and  approved  prior  to  the  end  of 
this  phase  (chapter  9). 

2-6.  Production  Phase.  This  is  the  period 
from  production  approval  until  the  last  sys¬ 
tem  item  is  delivered  and  accepted.  The  objec¬ 
tive  is  to  efficiently  produce  and  deliver  effec¬ 
tive  and  supportable  systems  to  the  usinp 
command(s). 

a.  The  product  specifications  define  the 
product  confipuration  baseline.  This  baseline, 
in  conjunction  with  the  development  specifi¬ 
cations.  acts  as  an  instrument  for  use  in  diap- 
nosinp  troubles,  adaptinp  the  computer  re¬ 
sources  to  environmental  and  operational  re¬ 
quirements  of  specific  site  locations,  and  de- 
sipninp  chanpes. 

b.  Functional  and  Physical  Confipuration 
Audits  are  performed  on  all  confipuration 
items  (chapter  6). 

c.  Provisions  should  be  made  in  contracts 
and  follow-on  support  arranpements  to  main¬ 
tain  the  cum  ney  of  the  equipment/computer 
propram  confipuration  and  associated 
documentation  in  accordance  with  AFR  65-3. 
Failure  to  properly  consider  these  provisions 
may  result  in  support  complications,  obsolete 
documentation,  and  costly  “modernization” 
proprams. 

d.  The  supportinp  and  usinp  commands 
continue  to  propram  for  resources  necessary 
to  support  the  computer  proprams  throuph- 
out  the  deployment  phase.  At  propram  man- 
apement  responsibility  transfer,  the  role  of 
the  implementinp  command  normally  termi¬ 
nates  except  for  identified  residual  tasks  and 
phase-out  responsibilities. 
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2-7.  Deployment  Phase.  This  period  com¬ 
mences  with  delivery  of  the  first  operational 
unit  and  terminates  when  the  system  is  re¬ 
moved  from  the  operational  inventory. 

a.  Operational  test  and  evaluation  (OT&E) 
is  performed  on  all  operational  configuration 
items  to  assess  the  system  operational  effec¬ 
tiveness  and  suitability  in  a  deployed  config¬ 
uration  (chapter  5). 

b.  The  CRISP  continues  as  an  active  docu¬ 
ment  during  this  phase.  It  is  the  basic  agree¬ 
ment  between  the  using  and  supporting 
commands  for  computer  resource  manage¬ 
ment. 

c.  After  a  system  is  in  operational  use, 
changes  to  computer  programs  may  be  neces¬ 
sary  to  remove  latent  errors,  improve  coding 
or  operation,  adapt  to  changes  in  system  re¬ 
quirements,  or  incorporate  knowledge  gained 
from  operational  use.  Based  upon  complexity 
and  other  factors  such  as  system  interfaces, 
constraints,  and  priorities,  control  may  vary 
from  on-site  management  to  complex  checks 
and  balances  with  mandatory  security  keys 
and  access  codes.  The  authority  to  change  the 
computer  programs  must  be  carefully  and 
specifically  delineated,  particularly  when 
security,  safety,  or  special  nuclear  restric¬ 
tions  are  involved. 

2-8.  Computer  Program  Development  in  the 
System  Acquisition  Life  Cycle.  Computer 
program  development  can  be  conceptualized 
as  the  computer  program  life  cycle  shown  in 
figure  2-1.  This  cycle  may  span  more  than  one 
system  acquisition  life  cycle  phase,  or  occur  in 
any  one  phase.  For  example,  a  mission  simu¬ 
lation  computer  program  may  undergo  all  of 
the  phases  of  the  computer  program  life  cycle 
during  the  conceptual  phase,  while  a  mission 
application  program  may  undergo  these 
phases  during  the  validation,  full-scale  de¬ 
velopment,  and  production  phases.  The  com¬ 
puter  program  life  cycle,  and  the  formal  ac¬ 
tivities  associated  with  it  (configuration 
management,  technical  reviews,  testing  and 
audits,  and  so  forth),  will  occur  at  least  once 
for  each  CPCI  during  the  system  acquisition 
life  cycle.  The  activities  need  not  be  sequen¬ 
tial,  instead,  there  are  potential  loops  bet¬ 
ween  all  the  phases.  For  example,  design  may 
reveal  problems  (for  example,  in  performance 
and  cost)  which  lead  to  the  revision  of  re¬ 
quirements  and  reinstitution  of  certain 
analyses.  Checkout  may  reveal  errors  in  de¬ 
sign,  which  in  turn  may  lead  to  redesign  or 
requirements  revision.  The  phases  of  the 
computer  program  life  cycle  are  discussed  be¬ 
low. 


a.  Analysis  Phase.  The  purpose  of  the 
analysis  phase  is  to  define  the  functional  per¬ 
formance  requirements  for  a  computer  prog¬ 
ram.  These  requirements  describe  the  func¬ 
tions  the  computer  program  configuration 
item  is  required  to  accomplish  as  part  of  the 
system.  Additionally,  the  functional  inter¬ 
faces  and  the  necessary  design  constraints 
are  defined.  This  phase  normally  begins  with 
the  release  of  the  system  specifications,  and 
terminates  with  the  successful  accomplish¬ 
ment  of  the  PDR.  During  this  phase,  various 
design  approaches  are  considered,  analyses 
and  trade-off  studies  are  performed  and  de¬ 
sign  approaches  selected.  The  authenticated 
development  specification  forms  the  baseline 
from  which  the  design  phase  initiates. 

b.  Design  Phase.  The  purpose  of  the  design 
phase  is  to  develop  a  design  approach  includ¬ 
ing  mathematical  models,  functional  flow 
charts,  and  detail  flow  charts.  The  design  ap¬ 
proach  should  also  define  the  relationship  be¬ 
tween  the  computer  program  components. 
The  detail  flow  charts  define  information  pro¬ 
cessing  in  terms  of  the  logical  flow  and  opera¬ 
tions  to  be  performed  by  the  set  of  computer 
instructions.  This  information  is  contained  in 
the  preliminary  product  specification  and  is 
normally  presented  and  reviewed  during  the 
CDR.  The  design  approach  should  be 
documented  in  a  preliminary  Computer  Prog¬ 
ram  Product  Specification  and  reviewed 
against  the  requirements  of  the  development 
specification  prior  to  initiating  the  coding 
phase. 

c.  Coding  and  Checkout  Phase.  The  coding 
and  checkout  phase  normally  follows  the  suc¬ 
cessful  accomplishment  of  the  CDR.  The  pur¬ 
pose  of  coding  is  to  translate  the  flow  charts 
into  computer  programs  and  data.  The  pur¬ 
pose  of  checkout  is  to  convert  the  initial  com¬ 
puter  program  code  and  data  into  an  opera¬ 
tional  computer  program.  The  determination 
that  a  computer  program  is  operational  is 
based  upon  checking  that  it  produces  correct 
outputs  when  operating  upon  predefined  in¬ 
puts.  This  first  check  is  usually  limited  within 
each  computer  program  and  upon  successful 
completion  leads  into  the  test  and  integration 
phase. 

d.  Test  and  Integration  Phase.  The  purpose 
of  the  test  and  integration  phase  is  to  test  the 
computer  program  against  the  requirements 
specified  in  the  computer  program  develop¬ 
ment  specification.  This  test  and  integration 
process  includes  the  indivdual  computer 
program  function  or  module  tests  and  ex¬ 
tends  through  total  computer  program  formal 
qualification  tests.  Integration  of  the  compu- 
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ter  program  with  the  total  system  is  also  ac¬ 
complished  and  tested  during  this  phase. 

e.  Installation  Phase.  The  installation 
phase  includes  the  loading  and  running  of 
computer  programs  which  have  been  success¬ 
fully  qualified  and  integrated.  It  may  include 
peculiar  adaptation  to  various  sites  for  multi¬ 
site  systems.  It  should  include  checkout  to 
establish  that  the  system  operates  with  a  re¬ 
quired  or  specified  level  of  confidence  in  sup¬ 
port  of  the  total  system  within  the  opera¬ 
tional  environment. 

f.  Operation  and  Support  Phase.  During 
the  operation  and  support  phase,  the  opera¬ 
tional  suitability  of  the  system  is  assessed. 
Also,  the  capability  of  the  computer  program 
to  operate  on  the  total  set  of  input  data  pre¬ 
sented  in  an  operational  environment  is 


evaluated.  The  support  of  a  computer  prog¬ 
ram  includes  all  resources  and  activities  re¬ 
quired  to  insure  that  the  computer  program 
continues  to  meet  the  required  operational 
capability.  These  activities  may  include  re¬ 
sponding  to  changes  by  modification  of  exist¬ 
ing  computer  programs  and  the  creation  of 
new  computer  programs.  Changes,  not  only  to 
the  computer  programs  themselves,  but  also 
to  the  associated  documentation  must  be  ad¬ 
dressed.  Incorporation  of  new  programs  or 
program  modifications  to  an  existing  system 
normally  requires  reaccomplishment  of  all 
the  phases  in  the  computer  program  life  cycle. 
Hence,  the  computer  program  life  cycle  is  a 
continuing  process  throughout  the  system 
acquisition  life  cycle. 
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Chapter  3 
PLANNING 


3-1.  Purpose.  This  chapter  provides  guidance 
in  planning  the  acquisition  and  support  of 
computer  resources.  This  guidance  applies  to 
the  case  in  which  the  computer  resources  are 
identified  during  the  course  of  system  or 
equipment  development  and  to  the  case  in 
which  the  computer  resources  are  known  to 
be  required  at  the  outset. 

3-2.  Establishing  Computer  Resource  Re¬ 
quirements.  Requirements  for  computer  re¬ 
sources  originate  in  a  number  of  ways^  (For 
example,  in  master  plans  for  commands  or 
other  organizations  or  as  a  result  of  specific 
mission  or  functional  analysis  studies.)  Com¬ 
puter  resource  requirements  may  originate 
as  a  result  of  system  development  efforts 
which  are  undertaken  in  response  to  a  vali¬ 
dated  required  operational  capability  (ROC) 
(AFR  57-1).  This  occurs  when  it  is  determin¬ 
ed  that  computer  equipment  and  computer 
programs  are  appropriate  solutions  to  the  de¬ 
sign  objectives.  Computer  resource  require¬ 
ments  may  be  stated  in  a  data  automation 
requirement  (DAR)  (AFM  300-12).  In  iden¬ 
tifying  and  stating  requirements  for  new  or 
improved  capabilities,  it  is  essential  to  con¬ 
sider  the  impact  of  computer  resources,  in¬ 
cluding  computer  programs,  on  the  system 
operation,  maintenance,  and  support.  The  re¬ 
quired  capability  must  consider  the  life  cycle 
mission,  intended  interface,  and  relationship 
with  existing  or  planned  systems.  When  in¬ 
itiating  a  requirement  that  may  be  satisfied 
by  computer  resources,  the  using  and  other 
participating  commands  should  consider: 

a.  Recognized  requirements  for  computer 
program  capabilities. 

b.  The  requirement  for  either  general  pur¬ 
pose  or  special  purpose  computer  equipment. 

c.  Requirements  for  operational  system 
availability. 

d.  Compatibility  considerations  relative  to 
interfacing  with  existing  systems. 

e.  When  desired,  the  preferred  program¬ 
ming  language  or  computer  equipment  and 
accompanying  rationale. 

f.  Known  or  predicted  requirements  for 
system  flexibility  and  growth. 

g.  Management  and  technical  training  re¬ 
quired  to  develop  or  maintain  expertise  to  op¬ 
erate  and  support  the  computer  programs 
and  equipment. 


h.  Factors  which  will  affect  development 
and  maintenance  pf  an  organic  computer 
equipment  and  computer  program  support 
capability. 

i.  The  computer  program  support  concept 
envisioned  relative  to  both  the  supporting 
and  using  command  resources,  including 
manpower. 

j.  Existing  computer  resources  which 
should  be  considered  in  the  conceptual  plan¬ 
ning  for  the  system. 

k.  Security  requirements  peculiar  to  com¬ 
puter  resources  including  requirements  for 
handling  classified  information  during  com¬ 
puter  processing. 

l.  Known  trade-offs  between  equipment 
and  computer  programs. 

m.  Feasibility  of  trade-offs  between  central 
versus  non-central  computer  resources  ap¬ 
proaches. 

n.  Capabilities  required  to  implement  V&V 
plans  for  computer  programs. 

o.  Special  environmental  considerations. 

p.  Other  considerations  pertinent  to  the 
computer  resources  requirements. 

3-3.  Development  of  Computer  Resource  Re¬ 
quirements.  Requirements-  for  computer  re¬ 
sources  evolve  from  overall  system  require¬ 
ments  as  a  result  of  applying  system  en¬ 
gineering  disciplines.  The  system  configura¬ 
tion  which  results  should  meet  the  total  sys¬ 
tem  mission  requirements  in  the  most  cost  ef¬ 
fective  manner.  This  result  can  only  be  ac¬ 
complished  by  insuring  that  every  element  is 
included  in  the  total  system  optimization.  In 
this  regard,  computer  resources  must  be  con¬ 
sidered  as  an  integral  part  of  the  system  and 
must  be  subjected  to'trade-off  and  optimiza¬ 
tion  studies  in  the  same  manner  as  other  ele¬ 
ments.  The  refinements  of  these  studies 
through  system  analyses  result  in  a  set  of 
requirements  (specifications)  which  establish 
in  detail  the  required  performance  of  each 
system  segment  and  configuration  item.  It  is 
through  this  systematic  application  of  en¬ 
gineering  principles  that  the  full  capability’ of 
computer  resources  can  be  achieved. 

3-4.  System  Studies.  Trade  studies,  related 
studies  and  analyses  are  performed  primarily 
during  the  conceptual  and  validation  phases, 
and  continue  throughout  the  system  acquisi¬ 
tion  life  cycle.  These  studies  and  analyses  are 
performed  to  determine  the  identification  of 
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alternative  approaches  and  the  sequence  of 
functions  within  these  approaches;  the  design 
requirements  imposed  by  the  functions;  and 
the  best  design  approach  to  satisfy  the  design 
requirements.  Only  reasonably  attainable  de¬ 
sign  approaches  should  be  pursued  consider¬ 
ing  technical  capabilities,  cost,  time, 
schedules,  resource  limitations,  technology, 
or  other  constraints  as  specified  in  the  system 
documentation.  These  studies  and  analyses 
are  conducted  by  the  implementing  command 
with  inputs  from  all  of  the  participating 
commands.  Supporting  and  using  commands 
may  also  conduct  studies  and  analyses,  as  re¬ 
quired,  in  support  of  operational  systems. 

a.  Trade-offs  between  alternative  methods 
of  achieving  a  requirement  may  be  required 
between  computer  equipment  and  computer 
programs.  For  example,  higher  level  lan¬ 
guages  may  simplify  programming  and  thus 
reduce  programming  costs,  but  for  real  time 
processing  systems  more  powerful  and  ex¬ 
pensive  computer  equipment  may  be  neces¬ 
sary  to  efficiently  process  computer  programs 
written  in  these  languages.  Therefore,  this 
trade-off  must  consider  the  number  of  items 
to  be  developed  and  the  expected  level  of 
computer  program  change  activity.  The 
number  of  items  to  be  procured  is  important 
since  computer  equipment  costs  are  incurred 
for  each  item,  whereas  the  computer  program 
development  cost  is  not.  Life  cycle  computer 
program  support  costs  are  a  major  considera¬ 
tion  in  this  trade-off. 

b.  Another  trade-off  may  involve  the  sizing 
of  the  computer  capacity  to  allow  for  flexibil¬ 
ity  and  growth.  Specification  of  minimum 
spare  capacity  is  essential.  Reprogramming 
to  optimize  coding  within  the  constraints  of 
the  computer  equipment  usually  increases 
the  complexity  of  the  computer  programs  and 
increases  cost.  An  assessment  should  be  made 
early  in  system  development  to  determine  the 
probable  level  of  computer  program(s)  change 
and  growth  activity  over  the  anticipated  life 
of  the  system.  This  assessment  should  be  re¬ 
flected  in  the  specification  of  computer 
equipment  spare  capacity  including  spare 
central  processing  time,  spare  memory  and 
spare  input/output  channel  capacity. 

c.  Other  trade-offs  may  be  performed  to  de¬ 
termine  the  optimum  programming  lan- 
guage(s)  for  the  computer  program  within  the 
specific  system.  The  trade-off  between  alter¬ 
native  higher  level  languages  or  assembly 
languages  should  consider  the  following: 

(1)  Programming  language  used  in  simi¬ 
lar  systems  (commonality). 

(2)  Personnel  resources  with  applicable 
rogramming  language  skills  (to  include  re¬ 


quired  training)  within  the  using  and  sup¬ 
porting  command. 

(3)  Predicted  level  of  computer  program 
change  activity. 

(4)  Impact  of  programming  language 
selection  on  computer  equipment  complexity. 

(5)  Computer  program  support  concept  to 
include  levels  and  cost  of  documentation  re¬ 
quired. 

(6)  Review  of  applicability  of  standard  or 
special  purpose  higher  level  programming 
languages. 

(7)  Suitability  of  the  language  (ease  of 
programming),  and  time  responsiveness. 

(8)  The  processor  independence  afforded 
by  the  higher  level  language;  that  is,  the  re¬ 
quirement  for  transferability  of  the  computer 
programs  to  other  computer  equipment. 

(9)  Existing  compiler  availability  and  the 
requirement  for,  and  attendant  cost  and 
schedule  impact  of,  compiler  development. 

(10)  The  impact  of  using  either  the  system 
equipment  or  an  additional  computer  facility 
for  support. 

(11)  Computer  program  development 
time. 

(12)  Translation  processing  time. 

d.  Trade-offs  between  hard-wired  digital 
processing  and  general  purpose  programma¬ 
ble  processing  may  be  required.  Certain  high 
speed  information  processing  requirements 
such  as  real-time  implementation  of  a  basic 
function,  not  likely  to  change  over  the  life  of 
the  system,  may  be  cost-effectively  im¬ 
plemented  with  hard-wired  digital  processing 
equipment.  Functions  likely  to  change  over 
the  system  life  cycle  may  be  most  cost- 
effectively  implemented  with  general  purpose 
programmable  techniques. 

e.  Studies  or  analyses  should  be  performed 
to  establish  minimum  design  characteristics 
of  the  computer  equipment.  The  following 
characteristics  should  be  considered,  when 
applicable: 

(1)  Cycle  time. 

(2)  Word  length. 

(3)  Memory  size,  type,  and  characteris¬ 
tics. 

(4)  Arithmetic  capability:  fixed  point, 
floating  point. 

(5)  Multiprocessor,  multicomputer,  single 
computer  configurations. 

(6)  Input/output  channels  and  configura¬ 
tion,  transfer  rates  and  interrupts. 

(7)  Power  fail  safe. 

(8)  Parity  checks. 

(9)  Interval  timer  and  real  time/line  time 
clocks. 

(10)  Address  and  instruction  traps. 

(11)  Number  and  type  of  registers. 
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(12)  Instruction  repertoire. 

(13)  Peripheral  equipment. 

(14)  Off-line  backup  storage  capacity. 

(15)  On-line  mass  storage  devices. 

(16)  Communication  options. 

(17)  Interrupt  structure. 

(18)  Sequential  logic  control/micro  prog¬ 
ram  control. 

(19)  Equipment  redundancy. 

(20)  Impact  on  facilities. 

(21)  Electromagnetic  interference. 

(22)  Security  features. 

f.  Other  studies  and  analyses  should  be 
performed  to  establish  minimum  computer 
program  design  characteristics.  The  following 
characteristics  should  be  considered,  when 
applicable: 

(1)  Executive/supervisor  features. 

(2)  Modularity  of  the  computer  programs. 

(3)  Types  of  computer  programs  required. 

(4)  Minimum  iteration  rates  for  various 
functional  processing. 

(5)  Computer  program  media. 

(6)  Accuracy  and  stability. 

(7)  Fixed  point  versus  floating  point 
arithmetic. 

(8)  Security  features. 

(9)  Existing  computer  programs. 

(10)  Restart,  restore  and  recovery  fea¬ 
tures. 

(11)  Computer/ Assembler  features. 

3-5.  Directives  and  Plans.  Directives  origi¬ 
nate  in  response  to  requirements  and  may 
direct  that  studies  and  analyses  be  performed 
to  validate  the  requirement,  or  to  establish 
major  trade-offs.  Later  the  program  man¬ 
agement  directive  (PMD)  (AFR  800-2)  au¬ 
thorizes  the  development  of  the  system  or 
equipment,  thereby  initiating  a  project  or 
program.  The  PMD  or  similar  document  may 
direct  that  a  plan  or  plans  be  prepared.  Plans 
for  computer  resources  are  prepared  in  con¬ 
sonance  with  the  plans  for  the  system  of 
which  they  are  a  part.  The  major'  computer 
resource  documents  are  the  PMD,  the  prog¬ 
ram  management  plan  (PMP),  the  computer 
resources  integrated  support  plan  (CRISP), 
and  computer  program  development  plan 
(CPDP). 

3-6.  Program  Management  Directive.  The 
PMD  is  issued  in  accordance  with  AFR  800-2. 
The  following  direction  may  be  included  in 
PMDs: 

a.  Identification  of  computer  resources 
technical  and  managerial  expertise  responsi¬ 
ble  to  the  program  manager  for  managing  the 
acquisition  of  subsystems  which  contain  com¬ 
puter  equipment  and  computer  programs. 
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This  includes  management  expertise  to  focus 
attention  on  computer  program  development 
and  integration  across  the  total  system. 

b.  Management  responsibility  for  the  in¬ 
tegration  of  computer  equipment  and  compu¬ 
ter  programs  into  the  overall  system  will  re¬ 
main  centralized. 

c.  Standardization,  within  each  system  as 
well  as  across  systems,  of  computer  equip¬ 
ment  and  computer  programs  will  be  applied 
to  the  maximum  extent  practicable. 

d.  Solicitation  documents  will  include 
explicit  statements  defining  Air  Force  rights 
to  computer  equipment  and  computer  prog¬ 
rams  required  to  operate,  simulate,  and  sup¬ 
port  the  system.  This  includes  computer 
programs  and  associated  documentation 
(content  and  media)  required  for  mainte¬ 
nance  and  modification. 

e.  Supporting  and  using  commands  will 
participate  in  the  requirements  definition, 
development,  audits,  test,  and  maintenance, 
and  major  modification  of  computer  programs 
and  equipment. 

f.  Acquisition  of  support  equipment  (such 
as  a  dynamic  avionics  integration  laboratory) 
and  documentation  will  be  identified  when 
determined  necessary  to  establish  organic  or 
competitive  contractor  support  facilities. 

g.  Computer  equipment  reliability,  main¬ 
tainability  and  availability  will  be  prime  de¬ 
velopment  objectives. 

h.  Functional  analyses,  trade-off  studies 
and  cost-effective  optimizations  will  be  per¬ 
formed  to  determine  and  define  a  low-risk  de¬ 
velopment  approach  to  computer  equipment 
and  computer  programs.  Modeling  and  simu¬ 
lation  techniques  will  be  used  when  approp¬ 
riate. 

i.  Existing  systems  or  proven  concepts  will 
be  considered  whenever  practical. 

j.  Computer  program  development  and 
support  requirements  will  be  defined  includ¬ 
ing  the  use  of  government  funded  equipment 
and  facilities. 

k.  System  capacity  to  provide  growth  capa¬ 
bility  consistent  with  the  anticipated  level  of 
computer  program  change  activity  and  ease 
of  computer  program  support  during  the  life 
of  the  system  will  be  evaluated. 

l.  Computer  equipment  and  computer 
programs  will  be  identified  as  configuration 
items. 

m.  Comprehensive  testing  of  computer  re¬ 
sources  will  be  performed  and  the  use  of  inde¬ 
pendent  V&V  of  computer  programs  should 
be  considered. 

n.  Computer  equipment  and  computer 
program  development  costs  will  be  identified 
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in  appropriate  work  breakdown  structures. 
Provisions  should  be  made  to  insure  proper 
identification  of  cost  data  by  the  contractor 
and  delivery  of  the  cost  data  to  the  Air  Force 
as  required. 

o.  Computer  equipment  and  computer 
programs  will  be  emphasized  in  design  re¬ 
views,  audits,  and  management  assessments. 

p.  The  Air  Training  Command  (ATC),  in 
conjunction  with  the  using  and  supporting 
commands,  will  initiate  plans  for  computer 
resources  training  programs. 

q.  The  Advanced  Procurement  Plan  will  re¬ 
flect  computer  resources  planning. 

r.  Computer  resources  planning  will  con¬ 
sider  life  cycle  costing  concepts. 

s.  The  development  of  a  computer  re¬ 
sources  integrated  support  plan  (CRISP)  will 
be  initiated  at  the  earliest  possible  phase  of 
the  system  acquisition  life  cycle. 

3-7.  Program  Management  Plan  (P.V1P).  The 

computer  resources  content  of  the  PM P  is 
prepared  by  the  implementing  command  in 
conjunction  with  supporting,  using,  and  other 
participating  commands.  It  includes  complete 
planning  for  the  acquisition  management  of 
the  computer  resources.  If  the  computer  re¬ 
sources' are  identified  later  in  the  program,  a 
change  to  the  PMP  will  be  published  covering 
such  resources.  The  PMP  coverage  of  compu¬ 
ter  resources  will  include  the  following,  when 
applicable: 

a.  Operational  and  support  concepts  for 
computer  programs  based  upon  studies, 
economic  analyses,  experience  and  participat¬ 
ing  command  inputs.  A  decision  for  organic 
support  must  be  based  upon  the  policies  of 
AFR  26-12. 

b.  Identification  of  technical  and  manage¬ 
rial  expertise  allocated  to  the  program  office 
for  the  acquisition  management  of  computer 
equipment  and  computer  programs. 

c.  The  system  engineering  approach  to  be 
followed  in  transforming  operational  needs 
into  computer  resources.  The  selection  from 
configuration  options  should  be  based  on  life 
cycle  costs. 

d.  A  discussion  of  the  appropriate  trade¬ 
offs  between  hardwired  digital  processing 
equipment  and  programmable  computers. 
The  discussion  should  include  design  risk, 
system  integrity  and  life  cycle  cost. 

e.  Standardization  and  commonality  con¬ 
siderations  used  in  determining  computer 
equipment  and  computer  program  require¬ 
ments. 

f.  Requirements  for  computer  program  and 


data  rights  consistent  with  the  planned  oper¬ 
ational  and  support  concepts. 

g.  A  master  schedule  of  major  milestones, 
key  events,  and  any  critical  actions  essential 
to  timely  development  of  computer  resources 
in  relation  to  the  total  system  acquisition 
schedule. 

h.  Identification  of  required  interfaces  be¬ 
tween  the  computer  resources  of  this  system 
and  other  systems. 

i.  A  discussion  of  the  requirements  for 
growth  capability  and  spare  processing 
capacity. 

j.  Requirements  for  acquisition  and  sup¬ 
port  of  documentation. 

k.  Requirements  for  simulation,  integra¬ 
tion  and  other  facilities  necessary  to  support 
computer  programs. 

l.  Configuration  management  concepts. 

m.  Criteria  for  the  transfer  of  program 
management  responsibility  and  system/ 
equipment  turnover. 

n.  Preparation  of  a  computer  resources  in¬ 
tegrated  support  plan  (CRISP). 

3-8.  Computer  Resources  Integrated  Support 
Plan  (CRISP).  The  CRISP  identifies  organiza¬ 
tional  relationships  and  responsibilities  for 
the  management  and  technical  support  of 
computer  resources.  It  functions  during  the 
full-scale  development  phase  to  identify  com¬ 
puter  resources  necessary  to  support  compu¬ 
ter  programs  after  transfer  of  program  man¬ 
agement  responsibility  and  system  turnover. 
The  CRISP  continues  to  function  after  the 
transfer  of  program  management  responsibil¬ 
ity  and  system  turnover  as  the  basic  agree¬ 
ment  between  the  supporting  and  using 
commands  for  management  and  support  of 
computer  resources.  The  following  items 
should  be  included,  as  applicable: 

a.  Offices  of  primary  responsibility  and 
management  focal  points  for  support  of  com¬ 
puter  resources  and  the  channels  of  com¬ 
munication  among  organizations. 

b.  Planning  for  configuration  management 
of  computer  programs  including  the  assign¬ 
ment  of  configuration  control  responsibilities 
during  the  deployment  phase.  This  planning 
will  reflect  the  operational  and  support  con¬ 
cepts  for  the  system. 

c.  Responsibilities  for  composite  system  in¬ 
tegrity  which  includes: 

(1)  Computer  storage  utilization. 

(2)  Computer  program  operating  time 
and  priorities. 

(3)  Computer  program  interface  tech¬ 
niques. 

(4)  Computer  program  baseline  integrity. 
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(5)  Utilization  of  computer  modules  and 

peripherals. 

d.  Documentation  required  to  support  each 
type  of  computer  program. 

e.  Responsibility  for  funding,  scheduling, 
and  system  integration. 

f.  Qualified  personnel  required  for  support¬ 
ing  computer  equipment  and  computer  prog¬ 
rams  together  with  training  requirements. 

g.  Computer  equipment  and  devices  re¬ 
quired  to  facilitate  computer  program 
changes,  including  acquisition  respon¬ 
sibilities. 

h.  Computer  programs  required  to  support 
computer  equipment  and  other  computer 
programs  including  acquisition  respon¬ 
sibilities. 

i.  V&V  of  computer  programs. 

j.  Plans  to  establish  and  operate  necessary 
support  facilities.  Common  and  existing 
facilities  will  be  used  whenever  practicable. 
The  size  and  scope  of  the  support  facility  will 
be  based  on  work  load  predictions. 

k.  Provisions  for  the  transfer  of  program 
management  responsibility. 

l.  Provisions  for  system/equipment  tur¬ 
nover. 

3-9.  Computer  Program  Development  Plan 
(CPDP).  The  CPDP  identifies  the  actions 
needed  to  develop  and  deliver  computer  prog¬ 
ram  configuration  items  and  necessary  sup¬ 
port  resources.  It  will  be  prepared  by  the  im¬ 
plementing  command  or,  if  the  development 
effort  is  contracted,  the  plan  may  be  prepared 
by  the  contractor  and  approved  by  the  im¬ 
plementing  command.  The  plan  should  ad¬ 
dress  the  following  items: 

a.  The  organization,  responsibilities  and 
structure  of  the  group(s)  that  will  be  design¬ 
ing,  producing,  and  testing  all  computer  prog¬ 
rams. 

b.  The  management  and  technical  controls 
that  will  be  used  during  the  development,  in¬ 
cluding  controls  for  insuring  that  all  perfor¬ 
mance  and  design  requirements  have  been 
implemented. 

c.  The  methodology  for  insuring  satisfac¬ 
tory  design  and  testing,  including  quality  as¬ 
surance. 

d.  The  development  schedule  for  each  com¬ 
puter  program  configuration  item  and  prop¬ 
osed  program  milestone  review  points. 

e.  The  procedure  for  monitoring  and  re¬ 


porting  the  status  of  computer  program  de¬ 
velopment. 

f.  The  resources  required  to  support  the 
development  and  test  of  computer  programs. 
Special  simulation,  data  reduction  or  utility 
tools  that  are  planned  for  use  in  the  develop¬ 
ment  of  comnuter  programs  should  he  iden¬ 
tified. 

g.  The  general  procedures  for  reporting, 
monitoring,  and  resolving  computer  program 
errors  and  deficiencies  during  development 
and  testing. 

h.  The  methods  and  procedures  for  collect¬ 
ing,  analyzing,  monitoring,  and  reporting  on 
the  timing  of  time  critical  computer  prog¬ 
rams. 

i.  The  management  of  computer  program 
development  masters,  data  bases,  and  as¬ 
sociated  documentation  including  its  rela¬ 
tionship  to  the  configuration  management 
plan. 

j.  Guidelines  and  checkpoints  for  insuring 
future  computer  program  growth,  modulari¬ 
ty,  and  ease  of  modification. 

k.  The  approach  for  developing  computer 
program  documentation. 

l.  Training  requirements  and  associated 
equipment  for  the  deployment  phase. 

m.  Engineering  practices  to  include:  stan¬ 
dards,  conventions,  procedures,  rules  for 
program  design;  program  structures  ami 
conventions;  display  and  logic  standards; 
input/output  signal  standards;  and  other  dis¬ 
ciplines  affecting  development. 

n.  Security  controls  and  requirements. 

o.  Simulation  techniques  and  tasks. 

3-10.  Computer  Resource  Working  Group 
(CRWG).  Initially  chaired  by  the  program  of¬ 
fice,  the  CRWG  consists  of  representatives 
from  the  implementing,  supporting,  and 
using  commands.  The  group  is  responsible  for 
preparation  and  update  of  the  CRISP  and  in¬ 
sures  that  necessary  elements  of  the  CRISP 
are  included  in  transfer  and  turnover  agree¬ 
ments.  The  CRISP  and  updates  will  be  ap¬ 
proved  by  the  program  manager  after  coordi¬ 
nation  with  the  appropriate  commands.  The 
chairmanship  and  membership  of  the  CRWG 
will  be  amended  after  the  transfer  of  program 
management  responsibility  and  system 
equipment  turnover  as  mutually  agreed  by 
the  supporting  and  using  commands.  (Nor¬ 
mally,  the  chairmanship  will  be  assumed  by 
the  supporting  command.) 
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Chapter  4 

ENGINEERING  M  A  N  A  G  E  M  E  N  T 


4-1.  Purpose.  This  chapter  provides  guidance 
in  the  engineering  management  of  computer 
resources.  Discussions  include  systems  en¬ 
gineering,  systems  engineering  documenta¬ 
tion,  and  technical  design  reviews. 

4-2.  Objectives  of  Engineering  Management. 

The  objectives  of  engineering  management 
are  described  in  AFR  800—3.  The  objectives  of 
engineering  management  it  regard  to  com¬ 
puter  resources  in  systems  are: 

a.  That  computer  resources  are  managed 
as  an  integral  part  of  the  total  system. 

b.  That  the  engineering  tasks  associated 
with  computer  resources  are  part  of  the 
mainstream  enginering  effort  throughout  the 
system  acquisition  life  cycle. 

4-3.  Baseline  Management.  A  fundamental 
concept  associated  with  engineering  man¬ 
agement  is  the  use  of  a  series  of  configuration 
management  baselines  which  aid  in  assuring 
an  orderly  transition  from  one  major  decision 
point  to  the  next  throughout  t he  system  ac¬ 
quisition  life  cycle.  The  output  of  the  system 
engineering  process  is  technical  data  which  is 
used  to  establish  baselines  to  which  config¬ 
uration  management  procedures  are  applied. 
A  prime  configuration  management  function 
is  the  documentation  of  the  functional,  allo¬ 
cated  and  product  baselines  (AFR  65-3). 
Baselines  are  established  at  discrete  points  in 
a  program  when  it  is  necessary  to  define  a 
formal  departure  point  for  control  of  future 
changes.  These  baselines  are  continuously 
updated,  serve  as  engineering  reference 
points  and  are  documented  by  specifications 
and  associated  data. 

4-4.  System  Engineering.  Although  systems 
are  not  identical,  there  is  a  fundamental, 
identifiable  process  for  arriving  at  engineer¬ 
ing  decisions  regardless  of  the  system  pur¬ 
pose,  size  or  complexity.  The  process  involves 
a  hierarchy  of  requirements  beginning  with 
the  using  command's  needs,  usually  stated  in 
operational  terms,  and  ending  with  detailed 
engineering  specifications  and  data.  Each 
level  of  requirements  leads  to  t  he  preparation 
of  subordinate  detailed  requirements  in 
terms  suitable  for  the  engineering  activity 
involved  until  the  entire  system  responsive  to 
the  using  command's  needs  is  described.  The 
system  engineering  process  is  a  network  of 
actions  with  v’ery  close  interrelationships. 


a.  A  system  must  be  developed,  produced, 
tested,  operated,  and  supported.  All  func¬ 
tional  performance  requirements,  therefore, 
are  derived  from  the  needs  of  these  functional 
areas.  The  system  elements  are  identified  and 
developed  to  meet  the  performance  require¬ 
ments  derived  from  the  functional  areas  of 
operations,  logistics  support,  test,  production, 
and  deployment.  For  example,  the  functions 
which  must  be  accomplished  for  successful 
performance  of  the  operations  functions  gen¬ 
erate  the  requirements  for  operations  equip¬ 
ment,  facilities,  computer  programs,  person¬ 
nel,  and  procedural  data.  Each  of  the  other 
functional  areas  generate  requirements  for 
its  respective  system  elements. 

b.  System  engineering  defines  the  system 
on  a  total  basis  so  that  the  design  will  reflect 
requirements  for  equipment,  computer  prog¬ 
rams,  facilities,  procedural  data,  and  person¬ 
nel  in  an  integrated  fashion.  It  provides  the 
source  requirement  data  for  the  development 
of  specifications,  test  plans  and  procedures.  It 
also  provides  the  data  required  to  define,  con¬ 
tract  for,  design,  develop,  produce,  install, 
checkout,  and  train  personnel  to  test,  operate 
and  support  the  system. 

4-5.  System  Engineering  Process.  The  system 
engineering  process  is  iteratively  applied  to 
the  interrelated  functional  areas  of  opera¬ 
tions,  logistics  support,  test,  production,  and 
deployment.  Each  application  of  the  process 
is  accomplished  to  define  and  optimize  the 
combination  of  system  elements  needed  to 
satisfy  the  requirements  of  a  functional  area. 
Applications  of  this  process  are  termed  func¬ 
tional  cycles. 

a.  The  initial  cycle  addresses  the  opera¬ 
tions  requirements  of  the  system.  The  inputs 
to  the  operations  area  include  the  operational 
concept,  operational  environment,  system 
constraints,  and  measures  of  effectiveness 
which  have  been  established  by  prior  system 
analysis.  The  output  of  this  cycle  is  a  descrip¬ 
tion  of  an  optimized  combination  of  system 
elements  for  the  performance  of  operations 
functions.  This  description  is  complete  only 
when  the  inputs  from  all  engineering  discip¬ 
lines  and  specialty  programs  have  been  in- 
t  egrated. 

(1)  Operational  requirements  are  iden¬ 
tified  through  functional  analyses.  The  objec¬ 
tive  is  to  define  a  baseline  of  functions  and 
function  performance  requirements  which 
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must  be  met  in  order  to  accomplish  the  opera¬ 
tional  requirements  of  the  system.  Each  func¬ 
tion  is  described,  including  a  statement  of  be¬ 
ginning  and  end  conditions;  that  is,  inputs, 
outputs,  and  interface  requirements.  Func¬ 
tions  are  identified  from  the  top  down  so  that 
subfunctions  are  recognized  as  part  of  larger 
functions.  Functions  are  arranged  in  their 
logical  sequence  so  that  any  specified  opera¬ 
tional  usage  of  the  system  can  be  traced  in  an 
end-to-end  or  in  a  closed-loop  path. 

(2)  The  functions  and  associated  criteria 
are  analyzed  and  translated  into  design  re¬ 
quirements.  The  design  requirements  are 
comprised  of  all  requirements,  including  de¬ 
sign  constraints,  that  have  a  bearing  on  the 
functions  being  analyzed. 

(3)  Engineering  studies  are  then  per¬ 
formed  to  determine  the  best  way  to  satisfy 
the  requirements  and  select  the  best  ap¬ 
proach  for  integrating  the  design  require¬ 
ments  into  a  total  system  configuration  in¬ 
cluding  computer  equipment  configuration 
items  and  computer  program  configuration 
items. 

b.  In  the  subsequent  functional  cycles,  the 
system  engineering  process  is  applied  to  de¬ 
termine  the  logistic  support,  test,  production, 
and  deployment  requirements  imposed  by  the 
selected  combination  of  system  elements.  The 
production  and  logistic  support  cycles  are 
concerned  with  the  requirements  to  produce, 
maintain,  and  support  equipment  and 
facilities.  The  test  and  development  cycles, 
however,  are  concerned  with  the  require¬ 
ments  imposed  by  ali  of  the  system  elements. 
(For  example,  personnel,  computer  programs, 
and  procedural  data,  as  well  as  the  equipment 
and  facilities  that  require  testing.)  The  out¬ 
puts  of  these  cycles  of  the  process  are  the 
descriptions  of  the  logistic  support,  test,  pro¬ 
duction,  and  deployment  elements. 

e.  Although  the  functional  requirements 
analyzed  in  each  cycle  are  based  upon  the 
characteristics  of  the  operational  elements, 
this  does  not  imply  that  the  operation  cycle  is 
completed  before  the  other  cycles  are  in¬ 
itiated.  At  each  level  of  definition,  from  the 
syst  in  level  down  to  the  component  level,  the 
requirements  imposed  by  logistic  support, 
test,  production,  and  deployment  are  consi¬ 
dered  in  the  system  optimization.  At  each 
level,  the  process  i  accomplished  for  each  of 
the  functional  evades  to-identifv  risks  and  to 
validate  the  decisions  which  must  he  made  at 
that  lee"' 

1-6.  System  Engineering  Documentation.  The 

detailed  system  engineering  documentation 


may  involve  time-line  sheets,  facility  inter 
face  sheets,  maintenance  sheets,  requirement 
allocation  sheets,  and  similar  documentation. 
In  some  cases,  summary  sheets  for  the 
documentation  of  powerload  schedules,- elec¬ 
trical  input/output  signals,  monitor  and 
checkout  requirements,  may  be  required.  In 
the  case  of  computer  programs,  documenta¬ 
tion  specifically  tailored  to  computer  program 
needs  may  be  necessary.  For  example,  the 
format  of  the  design  sheet  may  not  be  approp¬ 
riate  for  specifying  the  design  requirements 
for  computer  programs.  In  this  case,  the  pre¬ 
liminary  development  specification  may 
serve  in  lieu  of  the  design  sheet.  The  choice  of 
documentation  format  must  be  made  on  an 
individual  program  basis  and  specific  system 
engineering  documentation,  if  needed,  must 
be  defined  in  hie  contract. 

4-7.  System  Engineering  Documentation 

Uses.  Use  of  system  engineering  documenta¬ 
tion  will  vary  depending  upon  the  system. 
Examples  of  the  type  of  tasks  and  products 
supported  by  this  documentation  follow, 
a.  Conceptual  and  Validation  Phases: 

(1)  Technical  inputs  to  the  DCP. 

(2)  Justification  and  rationale  for  pro¬ 
curement  of  technical  data  including  compu¬ 
ter  program  documentation. 

(3)  Work  breakdown  structures  and 
specification  tree  including  computer  prog¬ 
rams. 

(4)  Initial  system  specifications  and  revi¬ 
sions  or  expansions  thereto. 

(5)  Reliability  and  system  effectiveness 
models. 

(6)  Test  concepts  and  overall  require¬ 
ments  to  support  test  planning  and  develop¬ 
ment. 

(7)  Statements  of  work  and  requests  for 
proposals. 

(8)  Contractor  proposals. 

(9)  Program  office  and  contractor  re¬ 
views. 

(10)  Performance,  design,  and  test  re¬ 
quirements  for  development  specifications. 

(11)  Preliminary  quantitative  and  qual¬ 
itative  personnel  requirements  information 
(QQPRI),  training  equipment  planning  in¬ 
formation  (TEPI),  and  procedural  data. 

(12)  Evaluation  of  contractor  proposals 
and  reports. 

I>.  Full-Scale  Development  and  Production 
Phases: 

(1)  Expansion  and  verification  of  the  sys¬ 
tem  specification  and  development  specifica¬ 
tions.  product  specifications  for  computer 
programs,  and  preparation  of  drawings. 
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(2)  Qualification  and  acceptance  test  re¬ 
quirements  for  inclusion  in  the  system 
specification  and  development  specifications, 
and  to  support  the  development  of  detailed 
test  procedures,  plans,  directives,  and  other 
test  documentation. 

(3)  Technical  reviews,  audits,  and  accep¬ 
tance  tests. 

(4)  Activation,  operations,  and  mainte¬ 
nance  data, 

(5)  Problem  evaluation,  test  result 
evaluations  and  required  change  definition 
during  testing. 

(6)  Update  QQPRI,  TEPI  and  procedural 
data. 

(7)  Define  training  programs. 

(81  Logistic  support  requirements. 

(9)  OT&E  test  equipment  development, 
test  procedures,  test  plans  and  other  test 
documentation. 

(10)  System  security,  system  safety  and 
nuclear  safety  requirements, 
c.  Deployment  Phase: 

(1)  Follow-on  test  requirements,  test 
plans  and  procedures. 

(2)  Problem  evaluation  and  required 
changes  to  follow-on  testing,  the  analysis  of 
system  test  data  and  follow-on  system  modifi¬ 
cation. 

4-8.  Technical  Control.  This  aspect  of  en¬ 
gineering  management  includes  planning  for 
and  control  of  the  technical  tasks  required  to 
progress  from  an  operational  need  or  re¬ 
quirement  to  the  deployment  and  operation  of 
the  system  by  the  user.  Formal  technical  con¬ 
trol  is  accomplished  by  technical  reviews  at 
discrete  milestones.  Informal  technical  con¬ 
trol  is  accomplished  through  periodic  techni¬ 
cal  interchange  meetings  and  independent 
reviews. 

4-9.  Formal  Technical  Reviews.  Integrated 
engineering  and  technical  direction  of  en¬ 
gineering  efforts  must  be  reviewed  on  a 
periodic  basis  to  determine  the  technical 
adequacy  of  contractor  efforts  in  meeting  sys¬ 
tem  requirements.  Technical  reviews  must  be 
conducted  to  evaluate  the  degree  of  ac¬ 
complishment  of  the  engineering  efforts  and 
to  insure  the  utilization  of  engineering 
documentation  by  the  contractor  as  detailed 
in  the  contract.  The  completeness  of  the  re¬ 
views  provide  the  basis  for  rendering  deci¬ 
sions  during  the  course  of  the  program  to  en¬ 
sure  that  the  system  design  integrity  is  main¬ 
tained,  technical  deficiencies  are  isolated,  and 
necessary  changes  are  identified  promptly. 
The  number  and  types  of  reviews  depend 


upon  the  complexity  of  the  systems  acquisi¬ 
tion.  The  formal  technical  reviews  are  specifi- 
callv  detailed  in  MI L-STD-499A  (USAF)  and 
MIL-STD-1521  (USAF).  They  are  as  follows: 
System  requirements  reviews  (SRRs),  system 
design  reviews  (SDRs),  preliminary  design 
reviews  (PDRs),  and  critical  design  reviews 
(CDRs).  The  supporting  and  using  commands 
will  participate  in  formal  technical  reviews  to 
assist  the  program  manager  in  assessing  the 
contractor’s  technical  performance  and  prog¬ 
ress  but  not  to  give  specific  direction  to  the 
coritraetor.  The  responsibility  for  directing 
contractor  effort  still  remains  with  the  prog¬ 
ram  manager. 

a.  System  requirements  reviews  (SRRs) 
are  conducted  when  a  significant  part  of  the 
system  functional  requirements  have  been 
established.  The  basic  purpose  for  conducting 
SRRs  is  to  evaluate  the  contractor's  respon¬ 
siveness  to  the  Statement  of  Work  and  his 
interpretation  of  the  system  or  system  seg¬ 
ment  specification  requirements.  The  specific 
documentation  to  be  reviewed,  the  technical 
depth,  the  tentative  schedule,  and  the 
number  of  reviews  must  be  contractually  es¬ 
tablished.  SRRs  may  result  in  technical  or 
engineering  management  realignment  to  as¬ 
sure  that  the  contractor’s  initial  technical  in¬ 
terpretation  of  the  contract  is  in  line  with 
program  objectives.  Computer  resources  per¬ 
sonnel  should  participate  in  these  reviews 
and  consider  at  least  the  following: 

(1)  The  functional  flow  diagrams  as  they 
are  related  to  computer  program  allocations. 

(2)  The  requirements  allocation  sheets 
for  computer  programs  and  related  interfac¬ 
ing  equipment. 

(3)  Integrated  test  plans,  schedules  and 
milestones  including  preliminary  computer 
program  requirements  for  possible  test 
equipment,  data  facilities,  etc. 

(4)  Trade  studies  to  support  computer 
program  and  related  equipment  definition. 

(5)  High  risk  areas  associated  with  com¬ 
puter  programs  and  related  interfacing 
equipment. 

b.  System  design  reviews  (SDRs)  are  con¬ 
ducted  to  review  the  system  documentation 
and  to  assess  the  degree  of  accomplishment  of 
the  engineering  management  activities.  They 
insure  that  the  system  definition  effort  pro¬ 
ducts  are  necessary  and  sufficient  to  proceed 
into  preliminary  design  of  selected  solutions 
for  allocated  requirements.  An  SDR  should  be 
conducted  as  the  final  review  prior  to  the 
submittal  of  validation  phase  products  or  as 
the  initial  full-scale  development  review 
for  systems  not  requiring  a  formal  validation 
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phase.  If  the  SDR  is  satisfactory,  the  contrac¬ 
tor  should  be  allowed  to  enter  into  prelimi¬ 
nary  design.  A  portion  of  an  SDK  should  ad¬ 
dress  the  allocated  requirements  for  compu¬ 
ter  resources.  Without  agreement  on  these 
allocated  requirements,  proceeding  with 
computer  program  preliminary  design  should 
be  avoided.  The  following  items  should  be  re¬ 
viewed  for  mutual  understanding  and  con¬ 
tractual  interpretation: 

(1)  The  results  and  progress  of  computer 
programs  and  related  equipment  trade 
studies. 

(2)  Computer  programming  techniques  to 
be  adopted. 

(3)  Programming  languages  to  be  used. 

(4)  Computer  resources  needed  for  de¬ 
velopment,  integration,  testing,  operation, 
training  and  support. 

(5)  Computer  program  interface  re¬ 
quirements.  It  is  important  to  identify  inter¬ 
face  requirements  to  be  controlled  by  the  de¬ 
velopment  specifications  and  those  to  be  con¬ 
trolled  by  the  interface  control  drawings 
(ICD). 

(6)  The  list  of  CPCIs  including  those  for 
support  and  test  equipment. 

(7)  Preliminary  development  specifica¬ 
tions  which  must  include  the  design  of  com¬ 
puter  programs  and  any  related  equipment. 

c.  Preliminary  design  reviews  (PDRs) 
should  be  conducted  for  each  configuration 
item  identified  as  part  of  the  system.  The 
purpose  of  a  PDR  is  to  evaluate  the  progress, 
consistency,  and  technical  adequacy  of  a 
selected  design  and  test  approach;  and  to  es¬ 
tablish  compatibility  with  program  require¬ 
ments  and  preliminary  design.  A  successful 
PDR  is  required  for  each  CPCI  prior  to  pro¬ 
ceeding  into  detail  design.  A  single  PDR 
treating  several  CPCIs  individually  may  be 
held  when  such  an  approach  is  advantageous 
to  the  program  manager.  This  depends  upon 
the  nature  and  complexity  of  the  computer 
programming  effort.  The  design  approach  for 
computer  programs  is  contained  in  portions  of 
the  product  specification.  The  initial  portion 
of  the  product  specification  (computer  prog¬ 
ram  functional  flow,  storage  allocation 
charts,  control  functions  description,  and 
structure  and  organization  of  the  data  base) 
describing  the  design  approach  should  be 
made  available  by  the  contractor  for  Air 
Force  review.  At  a  PDR  and  from  a  compu¬ 
ter  resources  point  of  view,  the  following  will 
typically  be  performed: 

(1)  Review  of  all  functional  interfaces  be¬ 
tween  a  CPCI  and  other  CPCIs,  and  between 
CPC^and  related  Equipment  CIs.  Action 


should  be  taken  to  insure  that  interface  de¬ 
sign  requirements  are  adequately  identified 
in  the  development  specification  and  that  im¬ 
plementing  solutions  to  these  design  re¬ 
quirements  are  in  Interface  Control  Draw¬ 
ings. 

(2)  Review  implementation  design  of 
word  lengths,  message  formats,  available 
storage,  memory  maps,  timing  and  si z i rig 
data,  operational  interfaces  and  other  consid¬ 
erations  included  in  the  development  specifi¬ 
cation. 

(3)  Review  the  CPCI  structure  as  a  whole 
emphasizing  computer  program  functions, 
computer  program  functional  flow,  storage 
requirements  and  allocations,  computer 
program  operating  sequences,  and  design  of 
the  data  base. 

(4)  Anal;,  -"  critical  timing  requirements 
and  estimated  running  times. 

(5)  Review  the  human  interaction  as¬ 
pects  of  the  CPCI. 

(6)  Review  CPCI  test  requirements, 
documentation,  and  tools. 

d.  Critical  design  reviews  (CDRs)  should  be 
conducted  on  each  configuration  item  to  de¬ 
termine  the  acceptability  of  detail  design, 
performance,  and  test  characteristics  de¬ 
picted  by  the  design  solution  specified  in  the 
draft  product  specification,  accompanying 
drawings,  and  other  engineering  documenta¬ 
tion.  For  computer  programs,  product  specifi¬ 
cations  cannot  be  finalized  until  after  the  de¬ 
velopment  effort  (coding  and  checkout)  is 
complete.  The  CDR  for  a  CPCI  is  a  formal 
technical  review  of  the  CPCI  design.  The  pur¬ 
pose  is  to  establish  the  integrity  of  computer 
program  design  at  the  level  of  flow  charts  or 
computer  program  logical  design  prior  to  cod¬ 
ing  and  testing.  For  complex  CPCIs  the  CDR 
may  be  performed  in  stages  as  the  logical  de¬ 
sign  of  computer  program  components  (CPCs) 
or  groups  of  CPCs  is  completed.  For  less  com¬ 
plex  CPCIs,  the  CDR  may  be  accomplished  at 
a  single  review  meeting.  The  primary  product 
of  the  CDR  is  the  formal  identification  of 
specific  computer  program  documentation  to 
be  released  for  coding  and  testing.  The  follow¬ 
ing  are  typical  of  what  is  performed  at  CDR: 

(1)  Establish  compatibility  and  traceabil¬ 
ity  of  design  with  the  development  specifica¬ 
tion. 

(2)  Analyze  detailed  flow  charts  and 
other  descriptive  documentation  to  establish 
compatibility  of  system  design. 

(3)  Insure  interface  requirements  are 
satisfied  and  ICDs  are  complete  and  ap¬ 
proved. 

(4)  Review  interactions  of  the  CPCI  with 
the  data  base. 
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(5)  Review  test  and  analytical  data  such 
;  s  logic  diagrams,  algorithms,  storage  alloca¬ 
tion  charts,  and  detailed  flow  charts  to  estab¬ 
lish  design  integrity. 

(6)  Review  draft  of  complete  product 
specification  with  exception  of  instruction 
listings  which  can  only  be  produced  after  cod- 
ing. 

(7)  Review  system  allocation  document 
for  CPCI  inclusion  at  each  scheduled  location. 

(8)  Review  test  plans  and  procedures  for 
satisfying  the  development  specification  re¬ 
quirements  including:  location  and  schedule, 
planning  factors,  test  objectives,  test  descrip¬ 
tion  (scope,  type,  and  range  of  values),  and 
data  reduction/analysis  (scope,  method  and 
presentation). 

(9)  Review  computer  loading,  iteration 
rate?,  processing  time,  and  memory  esti¬ 
mates. 

4-10.  Technical  Interchange  Meetings.  The 

formal  technical  reviews  provide  a  means  for 
the  program  office  to  periodically  determine 
the  technical  status  of  a  computer  program 
development  effort  and  to  make  certain  man¬ 
agerial  decisions  on  the  adequacy  of  design, 
documentation,  testing,  etc.  These  reviews, 
however,  are  often  separated  by  a  considera¬ 
ble  length  of  time  and  may  result  in  an  in¬ 
complete  picture  of  contractor  progress.  For 
the  program  office  to  be  able  to  obtain  a 
realistic  picture  of  contractor  progress  and  to 
maintain  control  of  the  development  process, 


the  program  office  and  the  using  and  support¬ 
ing  commands  should  create  a  close  working 
relationship  with  the  contractor.  A  good  ap¬ 
proach  is  to  conduct  frequent  technical  inter¬ 
change  (TI)  meetings  at  the  contractor’s  facil¬ 
ity.  The  format  and  content  of  TI  meetings  is 
left  to  the  discretion  of  the  program  office. 
Consequently,  TI  meetings  are  a  very  flexible 
and  powerful  tool  for  progress  measurement 
add  engineering  control.  Generally,  a  TI 
meeting  covers  cost  status,  schedule  status, 
and  technical  status/problems.  Listed  below 
are  some  significant  points  pertinent  to  com¬ 
puter  resources,  to  consider  in  relation  to  TI 
meetings: 

a.  The  frequency  of  TI  meetings. 

b.  Representation  at  TI  meetings.  The 
program  manager  and  the  using  and  support¬ 
ing  commands  should  be  represented  by  per¬ 
sonnel  with  computer  expertise  and  familiar¬ 
ity  with  the  development  effort. 

c.  Actual  versus  planned  progress. 

d.  Possible  misinterpretation  of  computer 
resource  design  or  functional  requirements. 

e.  Actual  versus  planned  expenditures  and 
manpower  alignments. 

f.  The  resolution  of  problems. 


4-11.  Independent  Reviews.  The  need  may 
arise  for  the  program  office  t»  perform  inde¬ 
pendent  reviews  to  solve  problems.  To  assist 
in  these  reviews  and  provide  specialized  ex¬ 
pertise,  the  program  office  may  need  to  call 
upon  other  Air  Force  agencies  or  contractors. 
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Chapter  5 


TESTING  OF  CO  Ml 

5-1.  Purpose.  This  chapter  provides  gui¬ 
dance  for  creating  and  accomplishing  a  test 
program  for  new  or  modified  computer  prog¬ 
rams  which  are  a  part  of  a  total  system  test 
program.  Commands  involved  in  computer 
program  management  in  the  deployment 
phase  will  apply  those  portions  of  this  chapter 
required  to  accomplish  testing.  The  principles 
of  AFR  80—  1  1  apply  to  testing  of  computer 
resources.  This  chapter  disc  u.-ses  events  and 
milestones  applicable  to  the  test  and  evalua¬ 
tion  (T&E)  of  computer  programs  within  the 
framework  of  that  regulation.  Computer 
equipment  testing  is  governed  by  the  same 
principles  that  apply  to  other  equipment  test¬ 
ing  and  is  discussed  only  in  relation  to  compu¬ 
ter  program  testing. 

5-2.  Test  and  Evaluation.  Responsibilities  of 
organizations  participating  in  the  develop¬ 
ment  test  and  evaluation  and  initial  opera¬ 
tional  test  and  evaluation  test  program  will 
be  specified  in  the  P.MD.  Major  program  test 
objectives  may  be  identified  in  the  Test  and 
Evaluation  Objectives  Annex  (TEOA)  of  the 
PMD.  Responsibilities  and  objectives  will  be 
amplified  to  an  appropriate  level  of  detail  in 
the  T&E  section  of  the  PMP.  in  the  T&E  Mas¬ 
ter  Plan  (AFR  80-14),  and  in  supporting  lower 
level  test  plans.  AFR  80-14  covers  the  entire 
spectrum  of  test  and  evaluation  for  systems. 
The  basic  types  of  test  and  evaluation  are 
development  test  and  evaluation  and  opera¬ 
tional  test  and  evaluation. 

5-3.  Development  Test  and  Evaluation 
(DT&E).  DT&E  evaluates  the  technology,  de¬ 
sign  and  engineering  of  systems.  It  is  the  re¬ 
sponsibility  of  the  implementing  command. 
Participants  in  DT&E  include  the  implement¬ 
ing  command,  the  contractor(s),  and  approp¬ 
riate  supporting  and  using  commands.  Con¬ 
trol  of  the  contractor  portion  of  the  test  prog¬ 
ram  is  established  by  contract  provisions  and 
specification  requirements.  DT&E  is  nor¬ 
mally  completed  prior  to  the  production 
phase.  The  I)T&E  effort  is  divided  into  two 
areas,  configuration  item  (Cl)  test  and  system 
level  test. 

a.  The  object  of  configuration  item  testing 
for  computer  programs  is  to  establish  each 
computer  program  configuration  item  ((’PCI) 
as  a  qualified  item  suitable  for  entry  into  the 
system  level  test  program.  This  qualification 


ITER  PROCRAMS 

is  accomplished  by  verifying  that  the  CI’CI 
meets  the  performance  and  design  require¬ 
ments  of  the  computer  program  development 
specification.  Contractor  personnel  normally 
conduct  CPCI  testing.  The  program  manager 
designates  representatives  to  monitor  the 
test  progress,  adherence  to  test  procedures, 
validity  of  collected  data,  and  performance  of 
the  computer  equipment  and  computer  prog¬ 
rams.  CPCI  testing  is  divided  into  informal 
and  formal  testing. 

(1)  CPCI  informal  testing  is  that  testing 
performed  by  the  contractor  at  his  discretion 
to  assist  in  the  development  of  the  CPCI,  pro¬ 
vide  visibility  regarding  the  progress  of  the 
development,  and  prepare  for  formal  testing. 
Air  Force  approved  test  plans  are  not  re¬ 
quired,  however,  the  informal  test  program 
should  be  described  in  the  computer  program 
development  plan.  Usually,  the  contractor 
will  use  internal  documentation  during  in¬ 
formal  testidg  and  this  information  will  be 
available  to  the  Air  Force  only  upon  demand. 
When  the  test  results  provide  an  indication  of 
contractor  progress  in  the  development  of 
CPCIs  they  should  be  summarized  in  periodic- 
progress  reports.  Informal  testing  continues 
throughout  the  full  scale  development  phase. 
Each  computer  program  component  (CPC)  or 
subprogram  should  pass  through  a  series  of 
operations  and  iterations  such  as:  desk  check¬ 
ing,  elimination  of  illegal  or  erroneous  in¬ 
structions,  parameter  tests,  functional  test¬ 
ing  with  controlled  data  inputs,  assembly 
testing  with  other  components  of  the  CPCI, 
performance  testing  with  simulated  inputs 
and  performance  testing  in  the  system. 

(2)  Formal  testing  is  that  portion  of  CPCI 
testing  which  is  conducted  in  accordance  with 
Air  Force  approved  test  plans  for  the  purpose 
of  verifying  that  the  CPCI  fulfills  the  re- 
qui  rements  of  the  development  specificat  ions. 
There  are  two  distinct  types  of  formal  testing, 
preliminary  qualification  testing  (PQT)  and 
formal  qualification  testing  ( FQT). 

(a)  PQT  is  designed  to  be  an  incremen¬ 
tal  process  which  provides  visibility  and  con¬ 
trol  of  the  computer  program  development 
during  the  time  period  between  the  critical 
design  review  (CDR)  and  FQT.  A  PQT  should 
be  conducted  for  those  functions  which  are 
critical  to  the  CPCI.  The  test  plan  should 
specify  (’PCs  or  functions  to  be  tested  dunnu 
the  PQT,  the  sequence  of  the  tests  and  die 
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performance  and  design  requirements  to  be 
tested.  The  contractor  should  submit  a  sepa¬ 
rate  test  procedure  for  each  function  or  CPC 
to  be  tested  to  the  monitoring  agency  prior  to 
the  test  for  review  and  analysis.  As  the  design 
progresses,  these  procedures  will  evolve  and 
should  become  a  part  of  the  FQT  test  proce¬ 
dures.  PQT  results  will  not  be  used  as  a  sub¬ 
stitute  for  FQT  results.  The  selection  of  func¬ 
tions  to  be  tested  during  PQT  may  be  based  on 
time  critical  requirements  (for  example,  the 
development  of  the  executive  function  of  an 
operational  CPCI  is  usually  designated  “time 
critical”  because  the  orderly  progression  from 
parameter  testing  to  assembly  testing  re¬ 
quires  the  timely  development  of  the  execu¬ 
tive  function)  or  performance  critical  re¬ 
quirements  (for  example,  the  tracking  func¬ 
tion  of  a  CPCI  for  an  on-line  radar  system 
may  be  designated  “performance-critical" 
due  to  the  utilization  of  new  tracking,  smoo¬ 
thing,  and  filtering  techniques). 

(b)  FQT  is  a  complete  and  comprehen¬ 
sive  test  of  the  CPCI  in  a  continuous  test 
period  prior  to  functional  configuration  audit 
(FCA).  It  is  conducted  after  the  design  pro¬ 
cess  culminates.  Each  function  of  the  CPCI 
should  be  tested  regardless  of  prior  PQT  test¬ 
ing.  The  FQT  procedures  should  be  main¬ 
tained  and  used  throughout  the  remainder  of 
the  system  acquisition  life  cycle.  This 
maintenance  should  include  the  addition  of 
new  tests  or  the  revision  of  existing  tests  to 
properly  test  all  functions  affected  by 
changes.  For  those  CPCIs  (such  as  a  utility 
program)  which  are  relatively  insensitive  to 
the  system  operations,  formal  qualification 
will  usually  be  conducted  at  the  development 
facility.  For  a  large  operational  CPCI,  the 
complexity  of  the  performance  requirements 
may  require  testing  in  the  operationally  con¬ 
figured  system  and  may  require  use  of  the 
system  test  location. 

b.  Integration  of  the  computer  programs 
into  the  system  is  performed  to  insure  that  all 
detected  deficiencies  and  marginal  conditions 
have  been  eliminated  and  that  the  computer 
programs  are  ready  for  the  system  level  test. 
Integration  testing  normally  occurs  after  in¬ 
stallation  and  checkout  of  the  test  site 
equipment  and  facilities.  Integration  testing 
is  >'-•  ’■d'y  performed  by  the  contractor  in  ac¬ 
cordance  with  an  approved  test  plan.  The  con¬ 
tractor  should  identify  and  document  all  as¬ 
pects  of  the  integration  activities.  Schedules 
will  be  prepared  and  all  support  requirements 
clearly  understood  including  requirements 
for  government  furnished  equipment,  compu¬ 


ter  time,  displays,  consoles,  communications, 
and  support  personnel. 

c.  The  objective  of  system  level  DT&E  is 
the  formal  qualification  of  the  system.  It  is 
conducted  according  to  the  system  level  por¬ 
tion  of  the  DT&E  plan  anu  assures  the  integ¬ 
ration  of  all  configuration  items  and  other 
system  components  into  a  complete  system.  It 
includes  development  tests  of  the  completed 
system  in  as  near  an  operational  configura¬ 
tion  and  environment  as  practicable.  The  im¬ 
plementing  command  conducts  the  effort 
with  appropriate  participation  of  the  contrac¬ 
tor^)  and  the  supporting  and  using  com¬ 
mands.  Air  Force  personnel  who  have  re¬ 
ceived  formal  system  training  should  perform 
test  operation  and  maintenance.  Sufficient 
emphasis  shoo'd  be  given  to  the  interaction  of 
the  computer  equipment  and  computer  prog¬ 
ram  CIs  within  the  system  and  methods  for 
testing  the  interactions. 

5-4.  Operational  Test  and  Evaluation  (OT&E). 
OT&E  determines  that  the  system  will  satis¬ 
factorily  perform  the  functions  for  which  it  is 
designed  in  the  mission  environment.  AFR 
80-14  requires  an  initial  operational  test  and 
evaluation  (IOT&E)  phase  of  OT&E  to  be  ac¬ 
complished  prior  to  the  first  major  production 
decision.  Thus,  this  element  of  OT&E  may 
overlap  certain  phases  of  DT&E,  normally  the 
system  testing.  The  phase  of  OT&E  con¬ 
ducted  after  the  first  major  production  deci¬ 
sion  is  follow-on  OT&E  (FOT&E).  OT&E  will 
normally  be  conducted  by  the  Air  Force  Test 
and  Evaluation  Center  ( AFTEC)  or  the  using 
command,  with  the  support  of  the  implement¬ 
ing  and  supporting  commands.  The  respon¬ 
sibilities  of  AFTEC  are  specified  in  AFR 
23-36. 

5-5.  Test  Documentation.  There  are  several 
types  of  documentation  which,  collectively 
contribute  to  an  effective  test  program: 

a.  The  DCP  presents  the  critical  questions 
and  issues  which  must  be  addressed  by  the 
total  system  test  program  (AFR  800-2). 

b.  The  PMD  will  amplify  or  supplement 
those  critical  questions  and  issues  as  neces¬ 
sary.  The  TEOA  (prepared  in  accordance  with 
AFR  80-14)  lists  the  major  objectives  of  the 
total  system  test  program.  The  purpose  of  the 
TEOA  is  to  insure  that  all  evaluations  of  the 
system  (or  parts  thereof)  are  conducted  using 
a  common  baseline. 

c.  The  PMP  in  outlining  the  development 
program  should  contain  a  schedule  and  sum¬ 
mary  of  the  segments  of  the  total  system  test 
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program.  It  indicates  how  the  test  program 
interrelates  with  the  total  program. 

d.  The  T&E  Master  Plan  (TEMP)  is  an 
overall  plan  which  identifies  and  integrates 
the  effort  and  schedules  of  all  T&E  to  he  ac¬ 
complished  in  the  system  development  prog¬ 
ram.  The  test  program  should  be  structured 
to  include  tests  which  will  provide  answers  to 
the  critical  questions  of  the  DCP  and  PMD. 
The  TEMP  for  major  programs  may  be  re¬ 
quired  by  the  PMD  to  be  forwarded  to  OSD.  It 
may  be  used  as  the  T&E  section  of  the  PMP. 

e.  In  addition  to  the  test  requirements  de¬ 
lineated  in  the  above  documents,  specific  test 
requirements  are  imposed  on  the  contractors 
through  the  system  specification  and  through 
the  computer  program  development  specifi¬ 
cations.  Each  system  specification  will  iden¬ 
tify  a  requirement  to  verify  each  performance 
and  design  requirement  contained  in  the 
specification.  Computer  program  develop¬ 
ment  specifications  will  idi-n'ify  test  ap¬ 
proaches  for  use  in  qualifying  me  CPCIs  (for 
example,  inspection,  analyses,  demonstra¬ 
tion,  and  formal  test).  They  should  identify 
known  contractor  requirements  for  govern¬ 
ment  furnished  equipment  and  facilities 
needed  for  support  of  the  computer  program 
test  and  evaluation.  They  should  designate 
any  performance  and  design  requirements  to 
be  verified  during  system  level  testing.  In¬ 
formal  testing  need  not  be  addressed  in  the 
specifications  except  where: 

(1)  The  informal  tests  must  be  ac¬ 
complished  as  part  of  an  integrated  test  prog¬ 
ram  involving  other  systems/equipment/ 
computer  programs. 

(2)  The  informal  tests  require  the  use  of 
government  furnished  test  facilities  or 
equipment. 

f.  Test  plans  are  formal  documents  which 
provide  detailed,  coordinated,  integrated,  and 
time-phased  planning  for  providing  answers 
and  solutions  to  the  critical  questions,  areas 
of  risk,  and  fulfilling  other  requirements  for 
test  identified  in  the  documentation  of  sub- 
paragraphs  a  through  e  above.  The  plans  di¬ 
rectly  support  the  TEMP.  There  are  usually 
at  least  three  test  plans;  DT&E,  10T&E,  and 
FOT&E.  (There  will  be  an  integrated  plan  for 
a  combined  DT&E/IOT&E.)  AFR  80-14 
specifies  responsibilities  for  preparing  these 
plans. 

(1)  The  portion  of  the  DT&E  plan  which 
encompasses  the  formal  CPCI  tests,  normally 
prepared  by  the  contractor,  establishes 
criteria,  methodology,  responsibilities,  and 
overall  planning  for  CPCI  testing.  The  plan 
should  include  information  related  to  the  pre¬ 


liminary  and  formal  qualification  tests  as  fol¬ 
lows: 

(a)  Specific  objectives  of  each  test. 

<b)  Locations  at  which  the  tests  will  be 
conducted  and  schedules  relative  to  miles¬ 
tones  in  the  overall  acquisition  schedule. 

(c)  General  methods  for  preparation  of 
input  data;  for  example,  simulation  or  gener¬ 
ation  vehicles  to  be  used. 

(d)  General  procedures  for  test  con¬ 
duct,  and  responsibilities  for  test  direction, 
operation,  and  observation. 

(e)  Data  recording  requirements. 

(fj  General  procedures  for  data  reduc¬ 
tion  and  analysis  of  test  results. 

(g)  Requirements  for  other  computer 
programs,  equipment,  and  facilities. 

(h)  Qualified  personnel;  that  is,  num¬ 
ber::,  responsibilities,  and  required  knowledge 
and  skills. 

(i)  Requirements  and  procedures  for 
controlling  and  documenting  the  CPCI  test 
program,  including  procedures  for  preparing, 
reviewing,  and  revising  documentation  of 
specific  test  procedures  and  requirements 
and  procedures  for  preparing  and  reviewing 
reports  of  individual  qualification  tests. 

(2)  The  DT&E  plan  will  contain  provi¬ 
sions  for  the  installation  and  checkout  of 
computer  programs  at  follow-on  installations. 
This  testing  will  include  the  loading  and  run¬ 
ning  of  computer  programs  which  have  been 
successfully  qualified  and  integrated  at  the 
system  DT&E  test  site. 

g.  Test  procedures  present  the  detailed 
steps  for  the  conduct  of  each  test  specified  in 
the  test  plans.  They  are  prepared  by  the 
agency  which  is  to  conduct  the  particular 
test.  The  following  policies  should  be  applied 
to  test  procedures  prepared  bv  contractors  for 
formal  (’PCI  DT&E: 

(1)  Procedures  will  be  prepared  for  each 
qualification  test  (PQT  or  FQT).  These  proce¬ 
dures  should  be  completed  prior  to  the  perti¬ 
nent  PQT  or  FQT  test  date.  The  PQT  and  FQT 
procedures  should  be  reviewed  by  the  Air 
Force  in  preliminary  form,  and  proposed 
changes  should  be  resolved  with  the  contrac¬ 
tor  prior  to  testing.  The  following  information 
should  be  included  in  the  test  procedures. 

(a)  Test  objectives. 

(b)  Location  and  schedule  of  the  test 
briefings,  debriefings,  and  any  associated 
data  reduction/analysis. 

(c)  Reference  to  applicable  test  plans, 
specifications,  manuals,  and  handbooks. 

(d)  Requirements  and  responsibilities 
for  console  operators,  test  directors,  technical 
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consultants,  data  analysts  and  other  test  per¬ 
sonnel. 

(e)  Requirements  for  other  computer 
programs  (other  than  the  CPCI  being  tested) 
or  equipment. 

(f)  Test  operating  procedures  which 
specify  how  to  initiate,  maintain,  terminate, 
and  restart  the  computer  program  operation. 

(g)  A  description  for  each  test  to  be  per¬ 
formed  which  includes  test  inputs,  outputs, 
expected  results,  reactions  to  be  verified,  and 
methods  of  verification. 

(h)  Requirements  and  procedures  for 
recording,  reduction  and  analysis  of  test  data. 

h.  Results  of  all  tests  should  be 
documented.  Informal  contractor  CPCI 
DT&E  need  not  be  formally  reported  to  the 
Air  Force,  however,  documented  test  results 
should  be  available  for  Air  Force  review. 
Formal  CPCI  test  results  will  be  reviewed  and 
approved  by  the  implementing  command. 
(PQT  and  FQT  are  normally  reported  sepa¬ 
rately.)  Other  testing  will  be  reported  in  ac¬ 
cordance  with  AFR  80-14. 

5-6.  Computer  Program  Validation/ 
Verification  (V&V).  This  paragraph  discusses 
computer  program  V&V  in  its  relationship  to 
the  computer  program  life  cycle. 

a.  Analysis  Phase.  A  review  of  all  available 
documentation  for  logic  and  completeness 
should  be  made.  A  gross  functional  simula¬ 
tion  of  certain  new  or  critical  aspects  of  the 
design  may  be  accomplished  to  study  system 
design,  system  level  tradeoffs  and  functional 
interfaces.  A  timing  and  sizing  study  should 
be  conducted  to  insure  that  the  proposed 
computer  system  is  adequate.  A  discrete 
event  simulation  of  the  computer  system 
using  a  specialized  simulation  language  may 
be  used  to  assist  in  this  study. 

b.  Design  Phase.  All  models  should  be 
checked  for  logic  and  completeness.  In  some 
cases  it  might  be  desirable  to  independently 
rederive  equations  to  insure  correctness.  A 
scientific  simulation  of  the  system  may  be 
produced;  that  is,  the  algorithms  are  coded  in 
a  higher  order  language  such  as  FORTRAN 
and  run  on  a  general  purpose  computer.  This 
type  simulation  is  used  to  develop  algorithms 
and  to  check  system  interfaces.  The  outputs 
from  such  a  simulation  may  be  useful  for  later 
comparison  with  actual  system  outputs. 

c.  Code  and  Checkout  Phase.  After  a  prog¬ 
ram  has  been  coded,  it  must  be  reviewed  to 
insure  that  it  agrees  with  the  program 
specifications.  This  can  be  accomplished  by 
cross-checking  the  code  itself  with  earlier 
specifications,  flow  charts,  and  so  forth,  or  by 


running  the  code  in  a  simulated  computer  en¬ 
vironment.  One  way  to  accomplish  this  type  of 
checkout  is  by  desk-checking;  that  is,  by 
manually  going  through  the  code  and  compar¬ 
ing  it  to  the  specifications.  Another  method  is 
a  correctness  proof;  that  is,  a  mathematical 
proof  that  code  performs  exactly  the  func¬ 
tions  given  in  the  coding  specifications  and  no 
others.  Correctness  proofs  are  only  practical 
for  relatively  small  routines.  A  variety  of  au¬ 
tomated  test  tools  are  available  for  static 
checking  of  code  as  explained  in  the  following: 

(1)  Comparators.  Programs  which  do  an 
instruction-by-instruction  comparison  on  two 
versions  of  the  same  program.  The  com¬ 
parator  flags  differences  thus  indicating 
where  a  program  has  been  changed. 

(2)  Editors.  Programs  which  find  and  flag 
coding  errors  and  produce  cross-reference 
listings. 

(3)  Flowcharters.  Programs  which  oper¬ 
ate  on  a  program  written  in  either  assembly 
or  higher  order  language  and  produce  a  flow¬ 
chart  of  the  program  This  flowchart  can  then 
be  compared  to  the  original  program  flow¬ 
chart. 

(4)  Logic/Equation  Generators.  Prog¬ 
rams  used  to  reconstruct  arithmetic  text  an< 
to  flowchart  assembly  language  programs. 

(5)  Pathfinders,  Traps  and  Traces.  Prog¬ 
rams  which  analyze  possible  paths  through  a 
given  program.  This  information  is  useful  for 
planning  test  cases. 

(6)  Interpretive  Computer  Simulation 
(ICS).  An  ICS  is  an  instruction-level  simula¬ 
tion  of  the  operational  computer  on  a  host 
computer,  usually  a  large  general  purpose 
machine.  The  host  computer  is  programmed 
to  act  on  an  operational  program  in  exactly 
the  same  way  the  operational  computer 
would  act.  The  host  computer  will  give  the 
same  results  bit-for-bit  as  would  be  produced 
by  the  operational  computer  under  the  same 
conditions,  using  the  same  inputs.  An  ICS 
gives  greater  insight  into  actual  computer 
program  operation  and  provides  greater 
diagnostic  facilities  than  could  be  obtained  by 
running  the  operational  program  on  the  op¬ 
erational  computer.  Also,  an  ICS  is  useful  for 
checking  out  computer  programs  in  cases 
where  the  operational  computer  is  unavaila¬ 
ble.  Output  from  an  ICS  can  be  compared  with 
output  from  a  scientific  simulation  as  a  check 
on  the  operational  program.  Drawbacks  of  an 
ICS  are  that  it  may  run  slower  than  the  com¬ 
puter  it  simulates,  will  not  identify  timing 
problems,  and  it  must  itself  be  subject  t 
V&V. 

d.  Test  and  Integration  Phase.  Several  dif- 
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ferent  types  of  simulation  are  used  in  the  test 
and  integration  phase. 

(1)  In  one  simulation,  the  operational 
program  is  run  on  the  actual  operational 
computer,  while  another  computer  is  used  to 
simulate  the  inputs  to  the  interfacing  elec¬ 
tronic  equipment.  The  operational  computer 
memory  and  electronic  interfaces  should  he 
monitored  to  obtain  data  for  program  perfor¬ 
mance  evaluation.  Ideally  the  analyst  should 
be  able  to  monitor  selected  registers  and  ad¬ 
dresses  of  the  operational  computer.  He 
should  be  able  to  stop  the  program,  change 
parameters,  restart  the  program  and  single- 
step  through  the  program.  He  should  also  be 
able  to  perform  traces,  traps  and  dumps  on 
selected  areas  of  the  operational  program. 

(2)  Another  simulation  is  similar  to  the 
above  except  that  some  system  equipment  is 
used,  in  addition  to  the  operational  computer. 
The  equipment  is  artificially  stimulated  so 
that  it  produces  realistic  inputs  to  the  opera 
tional  program.  The  same  computer  monit< 
and  control  capabilities  are  needed.  T1  .- 
method  is  especially  useful  for  equipment/ 
computer  program  integration. 

(3)  A  further  simulation  uses  system 


equipment  and  some  live  inputs;  for  example, 
the  use  of  a  radar  set  against  actual  aircraft 
in  flight.  Again,  this  method  is  useful  for 
overall  systems  integration.  The  last  stage  in 
test  and  evaluation  is  operational  testing  (for 
example,  flight  testing  for  an  Operational 
Flight  Program),  preferably  with  special  in¬ 
strumentation  to  record  pertinent  data.  If 
nearly  identical  test  conditions  are  main 
tained  in  the  simulation  and  the  operational 
tests,  the  results  of  tlu  two  tests  can  be  com¬ 
part'd.  If  close  agreement  is  observed  in  the 
data,  a  high  degree  of  confidence  may  be 
given  to  the  simulation  tests  and  more  re¬ 
liance  can  be  placed  on  this  type  of  testing  in 
the  future. 

e.  Operational  and  Support  Phase.  V&V  is  a 
process  which  must  continue  through  the  sys¬ 
tem  life  cycle.  Whenever  changes  are  made  to 
equipment  or  computer  programs,  the  opera¬ 
tional  program  must  be  retested.  Simulations 
are  useful  for  reproducing  operational  prob¬ 
lems  and  for  retesting  the  system.  Simulation 
tools  and  accompanying  documentation 
should  be  identified  in  the  CRISP  and  ac¬ 
quired  at  the  same  time  the  system  is  ac¬ 
quired. 
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Chapter  6 

CONFIGURATION  MANAGEMENT 


SECTION  A— GENERAL  CONCEPTS 

6-1.  Purpose.  This  chapter  contains  guidance 
to  assist  Air  Force  activities  in  applying  the 
configuration  management  practices  and 
procedures  of  AFR  65-3  to  computer  re¬ 
sources  throughout  the  system  acquisition 
life  cycle.  It  provides  additional  information 
that  is  unique  to  computer  programs  and  gui¬ 
dance  in  the  application  of  'configuration 
management  principles  to  computer  program 
acquisition,  operation  and  support. 


6-2.  Configuration  Management.  Configura¬ 
tion  management  is  a  discipline  applying 
technical  and  administrative  direction  and 
surveillance  to  (a)  identify  and  document  the 
functional  and  physical  characteristics  of  sys 
terns  and  configuration  items;  (b)  contt  . 
changes  to  those  characteristics;  and  (c)  .  e- 
cord  and  report  change  processing  and  im¬ 
plementation  status.  Configuration  manage¬ 
ment  is  also  the  means  by  which  design,  en¬ 
gineering  and  cost  trade-off  decisions  are  re¬ 
corded,  communicated,  and  controlled. 


6-3.  Configuration  Management  Environ¬ 
ments.  Configuration  management  require¬ 
ments  may  be  subject  to  different  environ¬ 
ments  during  a  system  acquisition  life  cycle. 
Several  examples  are: 

a.  When  the  implementing  command  ac¬ 
quires  a  system  by  contract,  the  contractor 
uses  those  practices  described  in  his  config¬ 
uration  management  plan.  This  normally  oc¬ 
curs  during  the  validation,  full  scale  de¬ 
velopment,  and  production  phases. 

b.  When  the  supporting  command  has  con¬ 
figuration  management  responsibility,  con¬ 
figuration  management  is  performed  in  ac¬ 
cordance  with  the  supporting  command’s  es¬ 
tablished  practices.  This  normally  occurs 
after  program  management  responsibility 
transfer  (PMRT)  (AFR  800-1). 

c.  When  the  supporting  and  using  com¬ 
mands  each  have  configuration  management 
responsibility  for  portions  of  the  system,  the 
division  of  responsibilities  is  documented  in 
mutual  agreements  between  the  commands 
and  incorporated  into  the  CRISP.  The  com¬ 
mands  coordinate  those  actions  affecting 
each  other’s  area  of  responsibility.  This  situa¬ 
tion  normally  occurs  during  the  deployment 
phase. 


6-4.  Principles  and  Practices.  In  developing  a 
configuration  concept  and  configuration 
management  plans,  the  following  applies: 

a.  Computer  programs  will  be  managed  as 
essentia!  system  elements  using  common  pro¬ 
cedures  tailored  to  recognize  their  unique 
properties. 

b.  Configuration  management,  as  specified 
in  AFR  65-3,  will  be  applied  to  each  computer 
program  configuration  item  (CPCI)  through¬ 
out  the  system  acquisition  life  cycle. 

c.  Configuration  management  will  be  es¬ 
tablished  as  early  as  possible  and  should  ad¬ 
dress  the  interrelations  of  the  implementing, 
supporting,  and  using  commands. 

d.  Approval  of  changes  to  computer  re¬ 
sources  will  be  in  accordance  with  AFR  57-4 
as  amplified  in  this  regulation. 

e.  Overall  responsibility  and  authority  for 
the  configuration  management  of  the  entire 
system  must  be  vested  in  one  manager.  This 
manager  must  have  the  primary  responsibil¬ 
ity  for  committing  resources  toward  the  ac¬ 
complishment  of  changes  to  the  system.  Au¬ 
thority  may  be  delegated,  based  on  mutual 
agreements,  to  other  commands  or  organiza¬ 
tions  where  operational  considerations  dic¬ 
tate. 

f.  After  system/equipment  turnover  and 
program  management  responsibility  transfer, 
the  using  command  may  have  control  over 
those  computer  programs  required  for  the  di¬ 
rect  performance  of  its  mission.  For  example, 
AFR  102-5  contains  special  provisions  for 
command  and  control  systems.  Whether  this 
be  data  input  to  the  system  or  the  actual 
computer  programs  will  depend  upon  mission 
requirements  and  the  design  of  the  system.  In 
those  cases  where  the  using  command  relies 
on  a  separate  supporting  command  to  effect 
changes,  the  using  command  provides  their 
approval  for  all  changes  made  to  the  compu¬ 
ter  programs  through  the  mutually  estab 
lished  configuration  control  procedures. 

g.  Computer  program  configuration  man¬ 
agement  must  not  be  fragmented  from  the 
overall  system  configuration  management. 
Interfaces  are  important  and  must  be 
specified  and  controlled.  Continuous  com¬ 
munication  between  the  equipment  and  com¬ 
puter  program  activities  is  essential. 
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SECTION  B— VALIDATION,  FULL-SCALE 
DEVELOPMENT,  AND  PRODUCTION 
PHASES 

6-5.  Identification.  Configuration  manage¬ 
ment  requires  the  identification  of  each  CPCI 
and  its  interfaces  within  the  system. 

a.  In  the  initial  phases  of  the  system  ac¬ 
quisition  life  cycle,  computer  program  re¬ 
quirements  together  with  design  and  qualifi¬ 
cation  requirements  are  documented  in  a  de¬ 
velopment  specification.  The  physical  design 
of  the  computer  program  is  documented  in  a 
product  specification  which  is  the  complete 
technical  description  of  the  CPCI  as  designed, 
coded  and  tested.  The  product  specification 
may  identify  other  information  used  for  oper¬ 
ation,  correction,  and  modification  of  the 
CPCIs.  The  organization  and  content  of  the 
specifications  should  be  tailored  to  the  func¬ 
tional  application  of  the  CPCI. 

b.  The  Air  Force  Logistics  Command 
(AFLC),  in  conjunction  with  the  Air  Force 
Systems  Command,  is  responsible  for  the  de¬ 
sign  and  maintenance  of  the  Air  Foice  CPCI 
numbering  system  subject  to  HQ  USAF  ap¬ 
proval  and  in  coordination  with  Air  Force 
major  commands. 

(1)  The  CPIN  will  be  an  unchanging  Air 
Force  unique  number. 

(2)  AFLC  issues  the  CPIN. 

(3)  The  CPIN  will  be  used  to  identify  each 
CPCI  and  associated  documentation  for  con¬ 
figuration  management  purposes.  It  will  be 
supplemented  to  reflect  changes  to  the  CPCI. 

(4)  The  CPIN  will  be  used  to  satisfy  the 
configuration  management  identification  re¬ 
quirements  of  the  implementing,  supporting, 
and  using  commands  wherever  practicable. 

(5)  Commands  may  supplement  the 
CPIN,  when  cost  effective,  to  provide  further 
identification  or  information. 

c.  Interfaces  between  items  of  a  system  are 
sources  of  design  requirements  or  constraints 
and  are  contained  in  the  development  specifi¬ 
cation.  Computer  programs  have  interfaces 
with  computers  and  other  system  equipment, 
other  CPCIs,  and  between  components  of  a 
complex  CPCI.  Inti  rface  control  drawings  are 
working  tools  which  implement  the  interface 
requirement  of  the  development  specifica¬ 
tion.  The  ICDs  document  interface  agree¬ 
ments  between  the  system  contractor  or  par¬ 
ticipants  and  should  not  be  used  as  a  substi¬ 
tute  for  stating  interfacing  requirements  in 
the  development  specification.  The  interface 
control  working  group  (ICWG)  serves  as  the 
official  communications  link  between  prog¬ 
ram  participants  to  resolve  interface  prob¬ 
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lems.  Guidance  on  interface  control,  use  of 
ICDs  and  the  functions  of  the  ICWG  can  be 
found  in  MIL-STD^183,  Appendix  II. 

6-6.  Control.  Change  control  is  the  most  ap¬ 
parent  and  formal  aspect  or  configuration 
management.  During  the  validation,  full 
scale  development,  production,  and,  in  some 
cases,  the  deployment  phase,  changes  are 
processed  by  engineering  change  proposals 
(ECPs)  or  as  modifications  under  the  provi¬ 
sions  of  AFR  57-4.  The  ECP  is  a  comprehen¬ 
sive  document  which  contains  provisions  for 
supplying  all  the  information  necessary  to 
make  a  thorough  evaluation  of  the  change 
and  its  impact  oh  the  entire  system.  WTien 
the  change  is  approved,  it  may  also  generate 
changes  to  system  documentation  such  as 
specifications  (through  a  Specification 
Change  Notice,  MIL-STD-490,  or  a  Notice  of 
Revi  ion,  MI L-STD-480),  drawings  and  lists, 
techn  cal  orders,  spare  parts  lists  and  pro¬ 
visioning  documents,  test  procedures,  and 
manuals  for  operation,  maintenance,  and 
training. 

a.  MIL-STD-480  describes  procedures  for 
configuration  control,  including  the  prepara¬ 
tion  and  processing  of  enginering  changes, 
deviations  and  waivers.  It  contains  an  appen 
dix  defining  configuration  management 
terms.  MIL-STD-483,  Appendix  XIV,  con¬ 
tains  procedures  for  processing  ECPs  to 
CPCIs  and  supp'ements  MIL-STD-480  for 
this  purpose. 

b.  The  configuration  control  board  (CCB)  is 
the  official  organization  empowered  to  act  on 
all  proposed  changes.  During  the  validation 
phase,  a  CCB  is  established  for  each  system  at 
the  program  office  level.  It  is  chaired  by  the 
program  manager  with  members  represent¬ 
ing  ,all  program  office  functional  areas, 
AFLC,  ATC,  using  commands,  the  ICWG,  and 
other  participating  government  agencies. 
Board  decisions  are  documented  on  a  config¬ 
uration  control  board  directive  (CCBD)  which 
also  contains  each  board  member's  position. 
The  CCBD  is  directive  on  all  personnel  who 
must  act  on  the  change.  The  CCB  acts  on  all 
CPCI  Class  I  ECPs.  All  CPCI  changes  must  be 
reflected  in  the  associated  documentation, 
since  this  is  the  only  tangible  and  visible  rep¬ 
resentation  of  computer  program  content. 

c.  Engineering  release  systems  are  inter¬ 
nal  procedures  and  standard  practices  which 
the  contractor  uses  to  assure  that  only  prop¬ 
erly  approved  data  is  released  to  contractor 
development  and  production  functions.  The 
program  manager  must  insure  that  the  con 
tractor  establishes  a  system  for  approval, 
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control,  and  release  of  CPCI  engineering 
data.  MIL-STD-483,  Appendix  X,  contains 
provisions  for  contractual  application  to  as¬ 
sure  the  contractor  has  an  adequate  en¬ 
gineering  release  system.  It  should  be  tai¬ 
lored  to  cover  all  CPCI  documentation. 

d.  AFSC  and  AFLC  will  use  the  time  com¬ 
pliance  technical  order  (TCTO)  to  distribute 
CPCI  changes  (use  of  the  TCTO  is  described  in 
TO  00-5-15).  The  TCTO  may  include  a  version 
description  document  (VDD)  and  a  specifica¬ 
tion  change  notice  (SCN).  Use  of  the  VDD  is 
described  in  MIL-STD-483,  Appendix  VIII. 
The  use  of  the  SCN  is  described  in  MIL- 
STD-490  and  MIL-STD-483,  Appendices  VII 
and  VIII. 

e.  When  the  using  command  has  configura¬ 
tion  management  responsibilitiesr  for  a  com¬ 
puter  program  the  VDD  and  SCN  or  other 
method  described  in  the  O/S  CMP  may  be 
used  to  distribute  CPCI  changes. 

6-7.  Status  Accounting.  Configuration  statu 
accounting  documentation  is  the  means 
through  which  actions  affecting  CPCIs  are 
recorded  and  reported  to  program  and  func¬ 
tion*]  managers.  It  principally  records  the 
“approved  configuration”  (baseline)  and  the 
implementation  status  of  changes  to  the 
baseline.  In  this  way  it  provides  managers 
with  confirmation  that  decisions  of  the  CCB 
are  being  implemented  as  directed.  Config¬ 
uration  status  accounting  has  its  greatest  ac¬ 
tivity  after  establishment  of  the  product  con¬ 
figuration  baseline.  Only  the  minimum  in¬ 
formation  necessary  to  manage  configuration 
effectively  and  economically  will  be  recorded 
and  reported.  The  command  having  config¬ 
uration  management  responsibility  should 
take  action  to  assure  that  any  Air  Force  ac¬ 
tivity  or  contractor  responsible  for  imple¬ 
menting  changes  to  CPCIs  reports  the  ac¬ 
complishment  of  these  changes  in  an  accurate 
and  timely  manner.  MIL-STEM182  contains 
data  elements  for  use  in  the  accounting  and 
reporting  process  and  allows  the  use  of  any 
data  content  and  format  necessary  to  perform 
status  accounting. 

6-8.  Audits.  Configuration  audits  are  per¬ 
formed  in  accordance  with  AFR  65-3  and 
MIL-STD-1521  (USAF)  to  verify  compliance 
with  specifications  and  other  contract  re¬ 
quirements.  The  audit  function  validates  ac¬ 
complishment  of  development  requirements 
and  achievement  of  a  product  configuration 
through  examination  of  the  CPCI’s  technical 
documentation.  MIL-STD-1521  contains  de¬ 


tailed  procedures  on  the  conduct  of  configura¬ 
tion  audits  and  should  be  used  as  a  basic  re¬ 
ference.  Two  kinds  of  audits  are  performed, 
functional  and  physical. 

a.  The  functional  configuration  audit 
(FCA)  is  a  review  of  test  or  analysis  data  to 
confirm  that  an  item,  as  designed  and  de¬ 
veloped,  meets  the  requirements  specified  in 
its  development  specification. 

b.  The  physical  configuration  audit  (PCA) 
compares  the  “as-built”  item  with  its  ap¬ 
proved  and  released  technical  documentation 
to  assure  the  documentation  is  complete.  It 
establishes  the  product  baseline  and  is  ap¬ 
propriate  for  operational,  maintenance  and 
support  purposes.  For  CPCIs  the  program 
listing  is  compared  to  the  product  specifica¬ 
tion  and  supporting  documentation  to  check 
for  adequacy  and  validity.  This  audit  is  essen¬ 
tial  for  CPCIs  because  the  product  specifica¬ 
tion  and  associated  documentation  represent 
the  complete  and  only  technical  description  of 
the  CPCI. 

SECTION  C—  PRODUCTION  AND  DE 
PLOYMENT  PHASES 

6-9.  Configuration  Management  Change  Con¬ 
trol.  Changes  to  the  CPCIs  must  be  controlled 
in  an  efficient  and  responsive  manner;  yet, 
provide  the  flexibility  required  to  meet  mis¬ 
sion  requirements.  CPCI  changes  are  clas¬ 
sified  as  Class  I  (design)  and  Class  II  (discre¬ 
pancy)  changes  and  are  defined  in  Appendix 
XIV  of  MIL-STD-483  (USAF).  These  changes 
are  required  for  different  reasons,  such  as 
problems  identified  in  the  field,  testing  con¬ 
ducted  at  a  support  facility,  new  mission  re¬ 
quirements,  and  engineering  modifications. 
(Care  must  be  exercised  to  avoid  confusing 
Class  I  and  Class  II  CPCI  changes  with  Class 
I  through  Class  VI  modifications  under  AFR 
57-4).  CPCI  changes  may  be  implemented  in¬ 
dividually  or  held  for  the  next  version  release 
of  the  computer  program,  computer  data,  or 
documentation.  This  decision  will  be  based 
upon  unique  system  and  using  command  re¬ 
quirements.  Change  control  must  provide  for: 

a.  Systems  engineering  reviews  to  deter¬ 
mine  the  inter  related  effects  between  CPCIs 
and  system  equipment. 

b.  Changes  which  involve  both  system 
equipment  and  computer  programs. 

c.  CPCI  Class  I  design  changes  not  affect¬ 
ing  system  equipment.  These  changes  may 
originate  as  a  problem  or  as  an  engineering  or 
mission  requirement.  Each  change  must  be 
examined  to  determine  any  impact  upon 
equipment  or  other  computer  programs. 
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When  the  change  affects  equipment  or  ex¬ 
ceeds  the  existing  organic  capabilities,  AFR 
57—1  procedures  apply. 

d.  C  PC  1  Class  II  changes  not  affecting  sys¬ 
tem  equipment.  These  changes  result  from  a 
discrepancy  and  are  not  design  or  equipment 
problems.  They  can  be  changes  to  the  CPCI  or 
the  associated  documentation. 

e.  Changes  to  computer  data  as  defined  in 
chapter  10. 

f.  The  assignment  of  available  resources  to 
develop  and  test  the  change  after  approval. 

g.  Tracking  all  changes  from  identification 
through  approval  and  implementation. 

6-10.  Operational/Support  Configuration  Man¬ 
agement  Procedures  (O/S  CMP).  The  basic- 
configuration  management  approach  con¬ 
tained  in  the  CRISP  will  be  detailed  further 
in  the  operational/support  configuration 
management  procedures  (O/S  CMP).  These 
procedures  will  be  written  by  the  supporting 
and  using  commands  in  conjunction  with  the 
implementing  command.  They  are  the  config¬ 
uration  management  procedures  to  be  used 
during  deployment  of  the  system.  These  pro¬ 
cedures  must  be  written  during  the  Full  Scale 
Development  Phase,  before  the  system  begins 
its  operational  life.  As  a  minimum,  the  O/S 
CMP  should  incorporate  the  provisions  of 
change  control  described  in  paragraph  6-9 
and  address  the  following: 

a.  The  relationships  of  all  commands  in¬ 
volved.  If  a  Computer  Program  Configuration 
Sub-Board  (para  6-llb)  is  required,  represen¬ 
tation  should  be  designated,  a  chairman  iden¬ 
tified,  and  authorities  specified. 

b.  The  reporting  of  problems. 

c.  The  method  for  processing  deficiency  re¬ 
ports  or  proposed  modifications. 

d.  Approval  authority  for  changes. 

e.  The  status  accounting  procedures  and 
responsibilities. 

f.  The  handling  of  emergency  changes. 

g.  The  methods  for  distribution  of  CPCIs, 
documentation  and  changes  thereto. 

h.  Situations  where  system  turnover  pre- 
ceeds  program  management  responsibility 
transfer. 

6-11.  Board  Reviews.  After  system/ 
equipment  turnover  and  program  manage¬ 
ment  responsibility  transfer,  the  configura¬ 
tion  control  board  (normally  the  Air  Logistic 
Center  CCB)  is  the  configuration  change  con¬ 
trol  authority.  In  large,  complex  systems  or 
when  the  using  command  has  some  change 
control  responsibility,  a  Computer  Program 
Configuration  Sub-Board  (CPCSB)  may  be 
required  to  facilitate  computer  program 
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<-  change  processing.  The  responsibilities  of  the 
R  CP.CSB  will  be  outlined  in  the  CRISP  and  de¬ 
tailed  in  the  O/S  CMP.  Board  membership  will 
s-  include  representation  from  the  supporting 
a  commands,  using  commands  and  appropriate 
it  engineering  personnel. 

>r  a.  The  configuration  control  board  (CCB) 
has  responsibility  for  all  changes  to  the  svs- 
n  tern  ami  its  configuration  items.  Its  members 
should  be  representatives  of  all  involved 
o  agencies  and  system  functional  areas  such  as, 
configuration  management,  engineering, 
n  programming,  system  analysis,  test,  pro¬ 
curement.  financial  control,  training,  and 
logistic  support.  This  board  will  assure  that 
all  system  impacts  of  CPCI  changes  including 
those  that  affect  equipment  or  other  eonipu- 
,.  ter  programs  have  been  evaluated,  changes 
n  to  system  documentation  have  been  iden- 
e  titled  and  the  resources  have  been  identified 
to  implement  the  change. 
e  b.  A  Computer  Program  Configuration 
Sub-Board  (CPCSB)  functioning  as  a  subordi- 
d  nate  element  of  the  configuration  control 
board  may  be  designated  for  computer  prog- 
e  ram  change  processing  as  follows: 
s  (1)  The  CPCSB  will  review  and  may  be 

g  delegated  approval  authority  for  CPCI  Class  I 
,f  changes  which  do  not  affect  system  equip- 
9  ment  and  can  be  accomplished  within  the 
existing  organic  resources  of  the  responsible 
command.  This  includes  Computer  Program 
Engineering  Change  Proposals. 

(2)  The  CPCSB  will  review  and  should 
have  approval  authority  for  CPCI  Class  II 
changes.  When  appropriate,  considering  the 
complexity  of  the  system,  the  board  may  act 
upon  CPCI  Class  II  changes  or  handle  these 
changes  by  means  of  a  screening  function. 

(3)  The  CPCSB  will  insure  that  all  CPCI 
changes  are  properly  coordinated  in  accor¬ 
dance  with  agreements  between  the  com¬ 
mands  involved  as  specified  in  the  O/S  CMP. 

(4)  The  CPCSB  will  insure  the  identifica¬ 
tion  of  all  costs,  required  testing,  changes  to 
system  documentation  and  affects  on  equip¬ 
ment  and  computer  programs  associated  with 
a  change. 

(5)  The  CPCSB  will  convene,  as  required, 
with  the  CCB  to  provide  technical  expertise  in 
regard  to  proposed  changes. 

c.  A  screening  function,  will  be  performed 
in  support  of  the  CCB  or  CPCSB.  The  extent 
to  which  the  screening  function  is  formalized 
depends  upon  the  complexity  of  the  system 
and  will  be  detailed  in  the  O/S  CMP. 

(1!  When  problems  have  been  identified, 
they  will  be  screened  to  determine  the  valid¬ 
ity  of  the  problem  and  the  CPCI  change  clas- 
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sification,  such  as  discrepancy  (Class  II)  or 
design  (Class  I). 

(2)  If  the  change  is  determined  to  be  a 
CPCI  Class  I  change,  it  will  be  submitted  to 
the  CPCSB  for  appropriate  processing, 

(3)  The  approval  and  implementation  au¬ 
thority  for  CPCI  Class  II  changes  may  be  as¬ 
signed  to  the  manager  of  the  screening  func¬ 
tion.  In  all  cases  the  CPCSB  and  other  af¬ 
fected  organizations  will  be  notified  of  the 
change. 

6-12.  Deficiency  and  Improvement  Reporting. 
In  the  production  of  any  complex  computer 
program,  errors  will  be  generated.  It  is  the 
responsibility  of  all  personnel  to  report  prob¬ 
lems  as  well  as  detected  errors.  Chapter  10 
provides  methods  for  identifying  and  report¬ 
ing  deficiencies,  malfunctions,  or  errors  and 
for  requesting  improvements  which  may  b 
implemented  to  meet  special  command  need 


£^13.  Computer  Resources  Integration.  Integ¬ 
ration  is  the  combining  of  the  computer  and 
its  computer  programs  with  the  associated 
equipment  to  establish  equipment/computer 
program  compatibility,  and  to  isolate 
program/interface  and  timing  problems.  The 
configuration  control  procedures  will  include 
the  integration  function  to  insure  control  and 
identification  of  related  changes  for  man¬ 
agement  attention. 

6-14.  Systems  Integration.  A  requirement 
exists  to  examine  the  change  or  modification 
across  various  system  elements.  In  avionics 
systems,  for  example,  changes  to  the  opera¬ 
tional  flight  program  could  impact  the  av¬ 
ionics  hardware,  associated  airborne  equip¬ 
ment,  flight  simulators,  automatic  test 
equipment,  operator  manuals  or  various 
combinations  of  the  above.  The  configuration 
control  procedures  will  provide  for  control 
and  identification  of  related  changes  for 
management  attention. 
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Chapter  7 
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7-1.  Purpose.  This  chapter  provides  guidance 
for  determining  the  need  for,  acquiring,  and 
controlling  computer  resources  documenta¬ 
tion,  both  organically  and  contractor  gener¬ 
ated.  It  describes  a  standard  set  of  documents 
for  computer  equipment  and  computer  prog¬ 
rams,  and  provides  guidelines  for  tailoring 
these  documents  to  meet  individual  system 
requirements. 

7-2.  Requirements.  Only  that  documentation 
necessary  to  satisfy  specific  needs  will  he  ac¬ 
quired.  The  requirements  for  documentation 
and  the  selection  of  documentation  should  re¬ 
ceive  continuing  evaluation.  Data  Item  De¬ 
scriptions  should  be  identified  and  developed 
to  insure  timely  and  adequate  systen 
documentation  throughout,  the  system  a 
quisition  life  cycle.  Each  phase  of  develop¬ 
ment  should  be  documented. 

a.  Documentation  is  needed  during  de¬ 
velopment  in  order  to  track  progress  and  pro¬ 
vide  information  for  management  visibility 
and  decision  making.  For  example,  specifica¬ 
tions  are  required  to  describe  the  computer 
equipment  and  computer  programs  in  terms 
of  design,  performance,  configuration  and 
test  requirements. 

b.  Documentation  is  needed  to  enable 
proper  life  cycle  support  and  maintenance  of 
the  computer  resources.  This  documentation 
should  be  maintained  and  updated,  as  re¬ 
quired,  for  each  change  to  the  system  or  sys¬ 
tem  operation. 

7-3.  Determining  Documentation  Require¬ 
ments.  Requirements  for  documentation  are 
generated  in  many  ways. 

a.  In  addition  to  cost-effectiveness  consid¬ 
eration  for  documentation  acquisition,  the 
P,\1D  or  similar  work  initiating  directives 
may  direct  spec  fie  tailored  approaches.  For 
example,  in  experimental  or  prototype  ac¬ 
tivities,  the  PMD  may  direct  the  acquisition 
of  only  that  documentation  necessary  to  as¬ 
certain  the  feasibility  of  a  design  approach 
The  PMD  may  limit  the  support  and  mainte¬ 
nance  alternatives  affecting  the  support  and 
reprocurement  data  requirements. 

b.  The  supporting  and  using  commands 
submit  data  needs  for  figure  operation  and 
support  within  tile  n  intr,iii;n  imposed  by 
the  initial  directives.  Tlo-  e  .  toman. I-  ideii 
tify  documentation  reqm  retneni  -  luring  'he 


early  phases  of  ttie  sy-tem  acquisition,  f  .u 
computer  re  -oiirces,  the  CRISP  provides  tin 
basis  tor  identifying  related  support  an 
n.ai  nt  e  n  once  i<  ten  men  t  at  i  on  re.  i  ui  re  me  nts 
Command  requiienietits  are  processe. 
through  a  data  management  office  iDM<) 
focal  point  as  established  by  A h  R  liu-l,  Tht- 
action  is  initially  accomplished  t>\  means  of  ; 
Data  t  uii.  The  support j ng  .md  using  c<*m 
murids  should  continually  review  and  updai* 
their  data  requirements  with  •  he  DM<>.  Dat; 
determination  is  not  limited  >  • .  ai,  nut  la :  Data 

Call.  It  is  a  fie x i Id e  and  contiuinrig  . . . 

The  potential  impact  on  procurement  dollar.- 
requires  that  ch.anges  in  data  r vqui  i  <  i-mi  .1  • 
must  he  communicated  as  soon  a-  possible. 

c.  The  DMO  should  evaluate  the  repute 
merits.  This  evaluation  should  itielude  several 
considerations:  the  type  of  ac.pn -it  nm.  as 
sociated  organic  capabilit  urn.  support  c,,n 
cepts,  uses  of  the  system  and  potential  needs 
for  data. 

d.  Consideration  should  he  given  t<>  the  op 
timum  use  of  deferred  ordering,  deferred  re 
quisitionmg,  and  accession  list  techniques. 
The  first  two  techniques  are  described  m 
AFR  3  10-  1  ami  ASPR  Sect  ion  7.  and  deal  wit  h 
deferring  selection  or  delivery  of  the  data 
specified  in  the  contract  until  the  actual  re¬ 
quirements  can  be  economically  determined, 
Use  of  these  techniques  should  he  evaluated 
to  avoid  impacting  data  needs  related  to  other 
system  (dements  such  as  Automatic  Test 
Equipment  (ATE).  The  Accession  last 
technique  requires  the  contractor  to  provide 
a  list  of  the  internal  data  he  is  generating  for 
his  own  use  in  the  performance  of  the  con¬ 
tract.  I  he  Ait  Force  can  acquire  this  data  m 
the  contractor’s  format,  however,  it  is  not 
subject  to  Air  Force  approval  or  a  delivery 
schedti  le. 

7  1.  Management.  I’he  implementing  com¬ 
mand  establishes  a  fecal  point  within  each 
plot  ."am  office  as  required  by  AFR  310-1  to 
manage  data  acquisition.  The  primary  re¬ 
sponsibility  ot  this  data  management  activity 
i-  to  insure  the  selective  application  and  ac¬ 
quisition  of  docu incut  at  ion. 

a  I  to*  DMO  should  track  all  data  require 
’  oil',  generated  in  the  t '  R  I S 1 V 

h  The  following  topics  should  be  const- 
de  I  a*'  1  t  in  m  .(computer  re  sou  rees  viewpoint  in 
docu  mo  nt  at  ion  management  plans: 
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(1)  The  source,  scope  and  ontent  of  the 
documentation  required. 

(2)  The  extent  of  Air  Force  rights  re¬ 
quired  to  satisfy  the  computer  program  sup¬ 
port  concept. 

(.2)  The  working  relationship,  points  of 
contact,  responsibilities,  communication  pro¬ 
cedures,  scheduled  review  cycles  and  controls 
for  changing  data  requirements. 

(4)  The  procedures  for  inspection  and 
testing  including  validation  of  the  data  by 
contractor  personnel  prior  to  delivery  to  the 
Air  Force  and  the  process  to  be  used  to  verify 
the  documentation. 

(f>)  A  schedule  showing  how  the  prepara¬ 
tion,  delivery,  and  review  of  computer  re¬ 
source  data  relates  to  major  program  miles¬ 
tones  such  as  SDR,  FDR,  ('DR.  FCA,  PCA, 
and  system  test. 

(6)  The  interface/interaction  of  computer 
resource  data  items. 

(7)  Procedures  for  review,  control,  and 
update  of  accepted  data  items. 

7-5.  Acquiring  Contract  Data.  The  DOD  au¬ 
thorized  data  list  (TD-.2)  identifies  standard 
data  item  descriptions  (DIDs)  for  use  in  ac¬ 
quiring  data  from  contractors. ' Examples  of 
DIDs  applicable  to  computer  resource  data 
requirements  are  shown  in  table  7-1.  The  con¬ 
tract  data  requirements  list  (CDRL)  is  used 
for  specifying  data  delivery  requirements  on 
contract.  Care  should  be  taken  to  tailor  the 
DIDs  to  actual  requirements. 

7-6  Modifying  Data  Item  Descriptions.  AFR 
.210-1  provides  guidelines  for  modifying  data 
item  descriptions.  The  contractor  data  pro¬ 
ducts  should  be  used  if  they  will  satisfy  the 
Air  Force  needs.  Certain  data  must  not  be 
modified  without  the  agreement  of  the  using 
and  supporting  commands  such  as,  data  re¬ 
quired  for  follow-on  test,  modification, 
maintenance  or  logistic  support.  Major  data 
item  descriptions  in  this  category  are  specifi¬ 
cations,  drawings,  technical  orders,  positional 
handbooks,  and  user  manuals. 

7-7.  Unique  Data  Item  Descriptions.  Data  not 
specified  in  the  authorized  data  list  (ADL) 
may  he  acquired  through  use  of  a  unique  or 
nonstandard  data  item  description.  These 
data  requirements  are  usually  program 
peculiar  or  command  peculiar  and  are  di¬ 
rected  toward  a  one-time  specific  application. 
These  items  are  created  by  the  agency  requir¬ 
ing  the  data,  and  submitted  for  approval  to 
the  Command  Data  Management  Office,  For 
computer  equipment  and  computer  programs, 


such  data  items  may  be  required  for  special 
design  information  such  as  programmer 
notebooks,  algorithm  development  studies, 
and  specialized  computer  program  listing 
printouts. 

7-8.  Division  Options  for  Computer  Program 
Documents.  For  large  computer  programs  and 
computer  program  components,  the  specifica¬ 
tions  or  associated  documents  may  be  logi¬ 
cally  divided  into  volumes  or  sections  to 
achieve  a  reasonable  document  size.  In  cases 
where  common  areas  wuthin  each  document 
may  be  combined  into  separate  documents, 
such  as  common  data  base  material,  the 
depth  of  coverage  must  be  consistent  with  the 
individual  documentation  requirements.  The 
division  options  should  be  specified  in  the 
CDRL. 

7-9.  partial  or  Incremental  Submittals.  It  may 
be  in  ‘.he  best  interests  of  the  Air  Force  to 
review  data,  especially  voluminous  data  such 
as  computer  program  product  specifications, 
incrementally.  Incremental  draft  submittals 
of  data  should  be  specified  in  the  CDRL  and 
the  actual  content  expected  with  each  sub¬ 
mittal  should  be  specified  in  backup  sheets  to 
the  data  items.  For  example,  partial  drafts  of 
the  product  specification  for  computer  prog¬ 
rams  could  be  submitted  in  three  or  more  in¬ 
crements.  The  top  design  flow  charts  could  be 
specified  for  delivery  prior  to  CDR,  the  com¬ 
plete  draft  except  for  listings  at  CDR,  and  any 
major  revisions  that  occur  after  CDR  in  sub¬ 
sequent  submittals.  Added  drafts  or  change 
pages  could  be  specified  to  be  delivered  when 
any  major  change  in  the  detailed  design  ap¬ 
proach  agreed  to  at  CDR  is  made  and  a  cur¬ 
rent  draft  should  be  provided  for  review  at 
the  PCA.  The  option  for  a  complete  review  of 
the  document  prior  to  final  acceptance  should 
be  maintained,  wherever  practicable. 

7-10.  Application.  Data  organically  generated 
or  contractor  prepared  can  be  discussed  in 
terms  of  primary  uses: 

a.  Many  of  the  organically  generated 
documents  are  used  to  establish  system  re¬ 
quirements  and  facilitate  acquisition  man¬ 
agement.  These  documents  are  the  required 
operational  capability  (ROC),  program  man¬ 
agement  directive  (PMD),  program  manage¬ 
ment  plan  (PMP),  computer  resources  integ¬ 
rated  support  plan  (CRISP),  and  the  compu¬ 
ter  program  development  plan  (CPDP).  The 
CPDP  may  be  an  organic  or  contractor  pre¬ 
pared  document.  These  documents  are  used 
by  the  program  manager  and  other  par- 
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ticipating  organizations  to  define  program  for  progressive  definition  of  technical  per- 
coneepts,  agreements,  and  planned  actions.  formance  and  relating  performance  require- 

b.  Contractor  prepared  data  may  include  ments  to  the  design  definition.  Specialized 

the  configuration  management  plan,  systems  types  of  data  are  not  usually  required  for 

engineering  management  plan,  human  factor  computer  resources,  but  documentation 

development  plan,  system  safety  plan,  per-  coverage  and  content  must  be  adjusted  to  ac- 

sonnel  subsystem  test  and  evaluation  plan,  count  for  their  peculiarities. 

and  computer  program  development  plan.  (3)  Test  documentation  is  used  for  the 

These  documents  are  used  to  evaluate  con-  qualification  and  acceptance  of  equipment 

tractor  proposed  approaches  to  system  de-  and  computer  programs,  and  to  provide  the 

velopment  and,  when  incorporated  into  the  basis  for  testing  future  modifications, 

contract  or  statement  of  work,  establish  con-  (4;  Operation  and  support  documentation 

tractual  requirements.  is  used  to  operate,  maintain,  modify,  and 

c.  Documents  used  for  procurement  pur-  otherwise  support  the  system  after  accep- 

poses  are  organically  prepared  and  include  tance.  The  uses  of  the  documentation,  indud- 

the  request  for  proposal  (RFP),  statement  of  ing  formats  and  reporting  procedures,  should 

work  (SOW),  and  the  contract.  be  discussed  in  the  CRISP,  O/S  CMP  and 

d.  Major  documents  for  monitoring  con-  command  manuals.  Specialized  documenta- 
tractor  performance  are  usually  contractor  tion  for  computer  programs  include  positional 
prepared  and  are  used  for  configuration  handbooks,  computer  programming  manuals, 
management,  engineering,  test,  system  oper-  user  manuals,  and  version  description  docu- 
ation,  and  support.  These  documents  can  be  ments. 

associated  with  the  computer  program  liC*  (5)  Specifications  are  engineering  docu- 

cycle  as  shown  in  figure  7-1.  Documentation  ments  used  to  define  the  management 

in  one  category  may  form  an  integral  part  of  baselines  as  departure  points  for  engineering 

other  categories.  For  example,  specifications  development.  configuration  control, 

are  used  for  design  and  development,  to  es-  documentation,  test,  and  support  activities, 
tablish  baselines  and  control  changes,  to  gen-  Specifications  provide  the  basis  for  document 
erate  test  plans  and  procedures,  and  for  up-  ing  requirements,  controlling  the  incremental 

dates  and  modifications.  Also,  certain  docu-  development  between  major  program  miles- 

ments  provide  a  basis  for  other  documenta-  tones  and  providing  visibility.  The  pecifica- 
tion.  The  operational  concepts  documents  and  tion  provides  a  level  of  control  that  is  initially 
computer  program  specifications  developed  broad  in  scope  and  progressively  narrowed  to 
as  a  part  of  the  engineering  activity  provide  become  more  restrictive  as  the  design  be- 
the  basis  for  the  computer  program  user  comes  definite.  MIL-STD-490,  M I  L-S-K.'U'.mi, 
manuals  and  handbooks.  and  MIL-STD-483  (I’SAFi,  establish  the 

(1)  Configi  ation  management  documen-  specification  documentation  for  systems,  sys- 
ation  is  used  to  establish  baselines  and  to  tern  segments,  computer  equipment,  compu- 

provide  methods  for  controlling  and  recording  ter  programs,  and  other  components  of  the 
changes  to  the  established  baselines.  system. 

(2)  Engineering  documentation  is  used 
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Primary  Output 
System  Functional 
Description 


System  Segment  Functional 
Description 


Products 

Requirements/ Allocation/Time 
Line  Sheets,  System  Specifica¬ 
tion  Analysis  Reports,  En¬ 
gineering  Design  Data 
Computer  Program  Dev  Plan, 
Development  Specification, 
Analysis  Reports,  Test  Plans, 
Trade  Studies,  System  Engi¬ 
neering  Management  Plan 


Phase 

System  Analysis  &  Require¬ 
ment  Definition 

System  Segment  Analysis 

Design 

Code  &  Checkout 

Test  &  Integration 

Installation,  Operate  & 
Support 


Detailed  (System  Segment) 
Design 


Computer  Programs 


Modifications 


Interface  Control 
Drawings,  Draft  Product 
Specification, 

Test  Plans 
Installation  Plans 
Personnel  Subsystems 
Test  and  Evaluation 
Task  Analysis, 
Programming  Manuals, 

( Draft)  User’s  Manuals, 
(Draft)  Positional 
Handbooks 

(Draft)  Training  Plans 

Timing  &  Sizing  Data 
Test  Plans  &  Procedures 


Revised  Documentation 


Test  Reports 

Testing  Results  of  Computer  Operating  &  Maintenance 
Programs  in  System  Manuals 

Product  Specifications 
Version  Description  Doc 


Figure  7-i.  Data  Related  to  the  Computer  Program  Life  Cycle. 
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Table  7-1.  Standard  Contract  Data  Items. 

CONFIGURATION  MANAGEMENT 

Configuration  Management  Plan 

Version  Description  Document  (Computer  Programs) 

Configuration  Index  (Computer  Program) 

Change  Status  Report  (Computer  Program) 

Engineering  Change  Proposals 

Specification  Change  Notice  (Computer  Program) 

Time  Compliance  Technical  Orders 

ENGINEERING  MANAGEMENT 

Contract  Work  Breakdown  Structure 
Data  Accession  List/Intemal  Data 

Engineering  Drawings  for  Design  Reviews,  Audits,  and  Evaluations 
System  Specification 

System  Segment  Specification  (Modification  Program) 

Configuration  Item  Development  Specification 
Computer  Program  Development  Specification 
Configuration  Item  Product  Fabrication  Specification 
Computer  Program  Product  Specification 
Inventory  Item  Specification 

Personnel  Subsystem/Human  Factors  Development  Plan 

Human  Operator  Task  Analysis  for  Information  Systems 

Personnel  Subsystem  Test/Evaluation  Plan 

Training  Needs/Exercising  Requirements  Analysis 

Reliability  and  Maintainability  Allocations,  Assessments,  etc. 

Reliability  and  Maintainability  Report  on  Commercial  Equipment 

Subsystem  Design  Analysis  Report 

System/Subsystem  Summary  Report 

Functional  Flow  Diagrams 

Requirements  Allocation  Sheets 

System/Design  Trade  Study  Reports 

Schematic  Block  Diagrams 

Time  Line  Sheets 

System  Engineering  Management  Plan 
Technical  Performance  Measurement  Report 
System  Safety  Plan 
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Chapter  8 

IDENTIFYING  CONTRACTUAL  REQUIREMENTS 


8-1.  Purpose.  The  purpose  of  this  chapter  is 
to  describe  the  responsibilities  of  the  program 
manager  in  identifying  for  the  appropriate 
contracting  authority  those  system  acquisi¬ 
tion  requirements  related  to  computer  re¬ 
sources.  Discussion  of  the  contract  and  its 
preparation  is  included  for  informational 
purposes. 

8-2.  Program  Management  Responsibilities. 
The  program  manager  will  insure  that  the 
requirements  for  the  management  of  compu¬ 
ter  resources  contained  in  this  regulation  are 
tailored  to  the  particular  system  acquisition 
and  submitted  to  the  appropriate  procure¬ 
ment  authority  for  inclusion  in  the  contrac¬ 
tual  instruments. 

a.  The  program  manager  provides  re 
quirements  to  the  procurement  authority  fy 
means  of  inputs  for  and  participation  in  tne 
preparation  of  the  procurement  package.  A 
typical  procurement  package  contains 
specifications,  instructions  to  offerers  (for  the 
preparation  of  proposals),  a  proposed  state¬ 
ment  of  work  (SOW),  and  a  contract  data  re¬ 
quirements  list  (CDRL,  DD  Form  1423). 

(1'  The  mission  and  technical  require 
ments  are  provided  in  the  procurement  pac¬ 
kage  in  the  form  of  performance  and  design 
specifications.  Depending  on  the  type  of  sys¬ 
tem,  these  requirements  are  specified  in  a 
system  specification,  a  system  segment 
specification,  or  a  similar  specification  docu¬ 
ment.  For  large  systems,  the  computer  prog¬ 
rams.  may  constitute  a  distinct  system  seg¬ 
ment  and  the  resulting  procurement  is  ac¬ 
complished  through  a  prime  contractor  in  as¬ 
sociation  with  other  system  segments  or 
through  a  separate  associate  contractor.  For 
smaller  systems,  the  procurement  may  be  ac¬ 
complished  through  a  prime  contractor  by 
means  of  one  system  specification,  with  com¬ 
puter  equipment  and  computer  programs 
identified  as  separate  configuration  items. 

(2)  The  instructions  to  offerors  provides 
for  the  format  and  content  of  each  offeror's 
proposal.  Where  computer  programs  are  in¬ 
volved,  the  program  manager  should  insure 
that  these  instructions  provide  for  prelimi¬ 
nary  contractor  plans  which  describe  the 
computer  program  development  concept 
(chapter  3).  Information  provided  may  be 
used  to  aid  in  the  evaluation  of  the  contrac¬ 
tor’s  capability  to  manage  computer  program 
development. 


(3)  The  contract  statement  of  work  iden¬ 
tifies  the  design,  engineering,  management, 
administrative,  and  support  tasks  that  are  to 
be  performed  during  the  life  of  the  contract. 
SOW  topics  are  discussed  in  paragraph  8-4. 

(4)  Deliverables  are  identified  in  the  con¬ 
tract  schedule  or  as  data  in  the  CDRL. 

b.  The  procuring  contracting  officer  (PCO) 
conducts  negotiations  between  prospective 
contractors  and  the  Air  Force.  The  program 
manager  or  his  representatives  participate  in 
the  negotiations  with  personnel  from  various 
disciplines  as  required.  The  negotiations  may 
result  in  modifications  to  the  contents  of  the 
system  specifications  or  contract  documents 
to  take  advantage  of  possible  tradeoffs  that 
can  result  in  cost  savings.  Technical  and 
managerial  requirements  which  are  modified 
or  waived  may  have  significant  impact  and 
should  be  considered  carefully.  Documenta¬ 
tion  related  to  computer  resources  required 
by  the  using  or  supporting  commands  should 
not  be  deleted  from  the  CDRL  without  ap¬ 
propriate  coordination.  The  program  man¬ 
ager  should  be  represented  in  the  negotia¬ 
tions  by  individuals  who  understand  both  the 
technical  and  management  aspects  of  compu¬ 
ter  programs.  The  Air  Force  rights  to  compu¬ 
ter  programs  and  associated  data  must  be 
identified  and  understood  by  all  parties  to  the 
negotiation. 

8-3.  Contract  Statement  of  Work.  The  prog¬ 
ram  manager  provides  the  required  contrac¬ 
tual  tasks  to  the  PCO  by  means  of  a  statement 
of  work.  The  contract  statement  of  work 
specifies  tasks  to  be  performed  during  the  life 
of  the  contract.  Tasks  are  described  below  in 
three  categories:  program  management 
tasks,  design  and  engineering  tasks,  and 
management  support  tasks.  The  SOW  is  tai¬ 
lored  according  to  the  complexity  and  mag¬ 
nitude  of  the  contractual  effort. 

a.  The  Program  Management  Tasks  in¬ 
clude  procedures  to  assure  an  orderly  man¬ 
agement  approach  to  the  contract  perfor¬ 
mance,  provide  a  means  to  continually 
evaluate  contractor  performance,  and  iden¬ 
tify  problems  and  suggested  corrective  ac¬ 
tions.  Topics  in  this  task  description  generally 
require  the  contractor  to:  develop  and  main¬ 
tain  plans  which  are  consonant  with  overall 
program  planning  for  the  computer  program 
life  cycle;  establish  and  maintain  manage¬ 
ment,  financial,  and  technical  controls  to  as¬ 
sure  identification  of  deviations  from  the 
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plans;  maintain  schedules,  forecasts, 
analyses  and  reports  for  each  functional  area 
of  the  computer  programs.  Certain  of  these 
topics  have  been  formalized  in  standardized 
management  systems  such  as: 

(1)  The  work  breakdown  structure  (WBS) 
task  requires  the  contractor  to  develop  a 
contract  WBS.  The  WBS  is  a  product  oriented 
family  tree  composed  of  equipment,  computer 
programs,  services,  and  data  items.  A  WBS 
organizes  and  portrays  the  product  as  well  as 
the  associated  work  to  be  accomplished. 
MIL-STD-881  describes  the  WBS  system  and 
is  authorized  for  use  by  both  the  Air  Force 
and  contractor  in  the  development  of  the  pre¬ 
liminary  project  summary  WBS  and  the  con¬ 
tract  WBS.  Computer  programs  should  be 
identified  at  level  3  in  the  project  WBS. 

(2)  When  cost  reporting  (AFR  800-6)  is 
applicable,  these  requirements  will  be  tai¬ 
lored  to  the  individual  contract.  Identifica¬ 
tion  of  computer  program  configuration  items 
at  level  3  of  the  WBS  will  provide  the  visibility 
necessary  to  evaluate  cost,  schedule,  and  per¬ 
formance  of  contracted  efforts. 

(3)  For  those  contracts  which  are  covered 
by  Contractor  Cost  Data  Report,  a  Contract 
Cost  Data  Reporting  Plan  will  be  prepared  to 
specify  cost  data  reporting  requirements.  The 
Contractor  Cost  Data  Reporting  Plan  and 
forms  as  described  in  AFR  800-6  should  re¬ 
quire  the  separate  identification  of  cost  as¬ 
sociated  with  CPCIs. 

b.  The  Engineering  and  Design  Tasks  are 
those  related  to  system  engineering,  design 
and  development,  test,  and  system  safety 
(chapter  4). 

c.  Management  Support  Tasks: 

(1)  In.  the  configuration  management 
task,  the  contractor  should  be  required  to  im¬ 
plement  a  Configuration  Management  Plan 
(chapter  6). 

(2)  In  the  data  management  task,  the 
contractor  should  be  required  to  supply  ap¬ 
propriate  data,  designate  a  focal  point  for  in¬ 
tegrating  the  data  management  effort,  de¬ 
velop  controls  for  data  preparation,  and  col¬ 
lect,  prepare,  publish  and  distribute  the  data 
in  the  quantities  and  types  designated  on 
the  CDRL. 

(3)  In  the  maintenance  and  support  task, 
the  contractor  should  be  required  to  identify 
all  of  the  computer  programs,  equipment,  and 
documentation  necessary  to  support  the  sys¬ 
tem  according  to  the  maintenance  and  sup¬ 
port  concepts.  The  appropriate  provisions  of 
the  CRISP  should  be  used  as  a  reference  for 
this  task. 


8-4.  Rights  in  Data  and  Computer  Programs. 

The  program  manager  should  insure  that 
contractual  provisions  reflect  requirements 
for  delivery  of  CPCIs  and  associated  data 
(chapter  7).  These  provisions  should  assure 
that  the  Air  Force  will  have  the  rights  to  use 
the  CPCIs  and  associated  data  to  meet  the 
support  concept  and  requirement  outlined  in 
the  CRISP.  The  program  manager  should 
consult  the  PCO  and  legal  counsel  (Staff 
Judge  Advocate)  in  connection  with  contract¬ 
ing  for  these  rights.  Local  Staff  Judge  Advo¬ 
cates  should  consult  higher  headquarters  on 
problems  not  previously  arising  in  their  com¬ 
mand.  Requirements  which  may  require  spe¬ 
cial  consideration  are: 

a.  The  right  to  order  computer  programs  or 
data  not  generated  under  the  contract. 

(1)  Privately  developed  computer  prog¬ 
rams  used  in  the  performance  of  contract 
work  or  data  pertaining  to  such  computer 
progr,  ms  or  other  items,  components  or  pro¬ 
cesses  used  in  the  performance  of  contract 
work. 

(2)  Privately  developed  computer  prog¬ 
rams  or  technical  data  needed  to  perform  op¬ 
eration  and  support  of  the  equipment,  compu¬ 
ter  programs,  or  other  itPtns  produced  under 
the  contract. 

b.  The  Air  Force  requirement  to  acquire 
computer  programs  or  rights  greater  than 
those  originally  set  out  in  the  contract.  For 
example,  the  right  to  use  computer  programs, 
subject  to  restricted  rights,  outside  the  Air 
Force  or  in  more  than  one  computer  or  instal¬ 
lation.  The  contractual  provisions  should  set 
out  the  results  of  any  predetermination  of 
rights  and  a  manner  under  which  the  Air 
Force  might  subsequently  acquire  additional 
required  rights. 

8-5.  Contract  Deliverables.  Contract  deliver¬ 
ables  are  specified  as  line  items  in  the  con¬ 
tract.  When  the  list  of  items  is  too  lengthy  to 
list  in  the  schedule  of  the  contract,  they  may 
be  listed  on  either  an  exhibit  or  attachment. 
When  deliverables  are  listed  on  an  attach¬ 
ment,  a  contract  line  item  or  sub-line  item 
must  be  set  forth  in  the  schedule  for  each 
deliverable  item.  While  computer  programs 
and  documentation  must  be  listed  on  the  DD 
1423,  the  DD  1423  should  be  identified  as  an 
exhibit  or  attachment  depending  on  the  re* 
quired  management  emphasis.  In  establish¬ 
ing  the  requirement  for  delivery  of  all  CPCIs, 
the  program  manager  should  consider  the  de¬ 
livery  of  all  media  necessary  for  planned  sup¬ 
port  of  the  CPCIs.  These  requirements  should 
be  included  in  the  contract.  The  deliverable 
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items  should  include  the  complete  source 
form  (tape  or  card  deck)  suitable  for  assembly 
or  compilation.  Additionally,  a  complete  ob¬ 
ject  form  (tape  or  card  deck)  suitable  for  load¬ 
ing  and  execution  in  both  the  operational 
computers)  and  any  computers  applied  to  di¬ 
rect  support  may  be  required. 

8-6.  Change  Control  and  Accounting  of  Com¬ 
mercial  Computer  Equipment  and  Computer 
Programs.  Appropriate  safeguards  should  be 
included  in  contracts  to  insure  that  the  con¬ 
tractor  reviews  all  subcontractor  or  vendor 
changes  and  that  all  computer  equipment  or 
computer  programs  in  a  system  are  main¬ 
tained  to  the  same  configuration  level.  The 
contractor  should  be  responsible  for  obtain¬ 
ing  these  changes  from  subcontractor  or 


vendor  and  maintaining  the  computer 
equipment  or  computer  .programs  to  the 
latest  released  configuration  as  required.  The 
contractor  should  also  be  made  responsible 
for  maintaining  the  engineering  compatibil¬ 
ity  between  all  system  equipment  and  compu¬ 
ter  programs,  including  incorporation  of  new 
subcontractor  or  vendor  released  versions  of 
computer  programs,  as  required. 

8-7.  Subcontractor  Management.  Computer 
resources  may  be  developed  under  a  subcon¬ 
tract  to  a  prime  contractor.  When  a  prime 
contractor  is  employed  in  a  system  acquisi¬ 
tion,  the  management  of  the  subcontractor  is 
by  the  prime  contractor  and  any  interaction 
with  the  subcontracted  task  by  the  Air  Fores 
is  effected  through  the  prime  contractor. 
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Chapter  9 

TURNOVER  AND  TRANSFER 


9-1.  Purpose.  This  chapter  identifies  the 
major  agreements  and  actions  necessary  to 
effect  the  system/equipment  turnover  and 
program  management  responsibility  transfer 
(PMRT)  of  systems  which  include  computer 
resources  from  the  implementing  command  to 
the  using  and  supporting  commands. 

9-2.  Policy.  Air  Force  regulation  AFR  800-19 
for  system/equipment  turnover  and  AFR 
800-4  for  program  management  responsibil¬ 
ity  transfer  will  govern  the  turnover  and 
transfer  of  computer  resources.  The  turnover 
and  transfer  of  computer  resources,  particu¬ 
larly  computer  programs,  must  be  considered 
during  the  preparation  and  coordination  of 
the  PMD,  PMP,  CRISP,  O/S  CMP,  and  tur¬ 
nover  and  transfer  agreements.  The  imple¬ 
menting  command,  supporting,  and  using 
commands  will  determine  the  responsibilities 
for  the  management  of  computer  resources 
that  are  identified  and  incorporated  into  the 
turnover  and  transfer  agreements.  The  Com¬ 
puter  Resources  Working  Group  should  in¬ 
sure  that  agreements  incorporated  in  the 
CRISP  are  in  the  system  turnover  and  trans¬ 
fer  agreements. 

9-3.  Documents.  Major  documents  associated 
with  the  turnover  and  transfer  of  computer 
resources  are: 

a.  The  CRISP  and  O/S  CMP  which  are  used 
in  developing  the  agreements. 

b.  The  PMRT  agreement  which  will: 

(1)  Include  appropriate  provisions  of  the 
CRISP  and  O/S  CMP. 

(2)  Identify  the  computer  resources  co¬ 
vered  by  the  agreement. 


(3)  Indicate  scheduled  delivery  dates  for 
the  computer  programs. 

(4)  List,  wherever  possible,  those  com¬ 
puter  programs  containing  major  discrepan¬ 
cies  or  omissions  as  of  the  PMRT  date. 

(5)  Indicate  any  special  change  proce¬ 
dures  and  phasing  requirements  for  the 
period  between  turnover  and  transfer. 

(6)  Indicate  the  status  of  completion  of 
the  system,  subsystem,  or  functions  affected 
by  computer  programs,  where  significant. 

(7)  Identify  provisions  for  completion  of 
training. 

(8)  Identify  computer  resource  action 
items  and  assign  responsibilities  for  their  ac¬ 
complishment. 

'9)  Incorporate  special  provisions  for  the 
man;  gement  of  computer  programs  common 
to  more  than  one  system. 

c.  The  system/equipment  turnover  agree¬ 
ment,  which  will: 

(1)  Incorporate  appropriate  provisions  of 
the  CRISP  and  O/S  CMP. 

(2)  Identify  the  computer  resources  co¬ 
vered  by  the  agreement. 

(3)  List  computer  resource  discrepancies 
and  exceptions. 

(4)  Incorporate  special  provisions  for  the 
management  of  computer  programs  common 
to  more  than  one  system. 

(5)  Indicate  any  special  change  proce¬ 
dures  and  phasing  requirements  for  the 
period  between  turnover  and  transfer. 

d.  The  turnover  certificate  which  lists 
computer  resource  deficiencies  and  excep¬ 
tions  at  the  time  of  turnover,  indicates  re¬ 
sponsibilities  for  corrective  action,  and  fore¬ 
casts  correction  dates. 
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Chapter  10 
SUPPORT 


10-1.  Purpose.  This  chapter  provides  addi¬ 
tional  guidance  for  the  management  of  com¬ 
puter  resources  during  the  Deployment 
Phase.  It  discusses  types  of  computer  prog 
rams,  computer  data,  reporting  procedures, 
and  interservicing  agreements. 

10-2.  Support  Objectives.  The  supporting 
command  will  provide  for  the  support  of  com 
puter  resources  according  to  the  following  ob¬ 
jectives: 

a.  Minimum  cost  consistent  with  mission 
requirements. 

b.  Consultation  with  and  guidance  for  the 
user  in  achieving  his  mission  requirements. 

c.  The  expeditious  correction  of  all  compu¬ 
ter  resource  deficiencies. 

d.  Introducing  state-of-the-art  improve 
ments  when  they  are  cost  effective  or  r> 
quired  to  satisfy  mission  requirements. 

10-3.  Planning.  The  using  command,  in  con¬ 
junction  with  the  supporting  and  implement¬ 
ing  commands,  develops  the  Maintenance 
Concept  in  accordance  with  AFR  66-14.  The 
supporting  command,  in  conjunction  with  the 
using  and  implementing  commands,  develops 
the  integrated  logistics  support  plan  in  accor¬ 
dance  with  AFR  800-8.  The  CRWG  develops 
the  CRISP  which  defines  the  concept  of  com¬ 
puter  resources  support  and  identifies  re¬ 
sponsibilities  (chapter  3). 

a.  Throughout  the  system  acquisition  life 
cycle,  the  implementing,  supporting  and 
using  commands  will  identify  computer  re¬ 
sources  and  associated  documentation  neces¬ 
sary  to  operate  and  support  the  system. 

b.  Periodic  assessments  will  be  made  to  de¬ 
termine  the  optimum  method  of  support  (that 
is,  organic,  contractor,  or  a  combination 
thereof;  AFR  26-12  applies).  This  assessment 
will  consider  the  requirements  for  program¬ 
ming  aids,  type  and  degree  of  simulation,  test, 
safety,  cost,  system  stability,  and  interface 
requirements. 

c.  The  CRISP  will  be  continually  updated 
to  reflect  the  current  support  concept. 

10-4.  Responsibilities.  Assignment  of  sup¬ 
port  responsibilities  and  authority  for  indi¬ 
vidual  computer  programs  will  be  determined 
by  its  impact  upon  system  equipment,  mission 
responsibilities  and  the  availability  of  both 
expertise  and  support  equipment. 


10-5.  Computer  Program  Types.  The  follow¬ 
ing  definitions  are  provided  for  categorizing 
computer  programs: 

a.  Operational.  Computer  Programs  re¬ 
quired  to  operate  the  system.  These  programs 
are  loaded  and  run  in  the  computer  equip¬ 
ment  during  system  operation  and  can  in¬ 
clude  the  following: 

(1)  Executive  Supervisor.  The  computer 
program  or  CPC  which  controls  the  execution 
of  functional/application  programs  and  the 
input, output  programs. 

(2)  Functional/Application.  The  compu¬ 
ter  program  or  (’PC  which  implements  func¬ 
tional  performance  requirements.  Examples 
are:  navigational  functions,  weapons  deliv¬ 
ery,  engine  performance  simulation,  and 
radar  tracking. 

(3)  Input/Output.  The  computer  program 
or  CPC  which  transfers  computer  data  bet¬ 
ween  the  computer  equipment  and  the  sys¬ 
tem  equipment. 

b.  Test.  Computer  programs  developed  to 
analyze  or  test  system  and  component  per¬ 
formance.  These  programs  may  be  integrated 
into  the  operational  computer  programs  as 
test  CPCs  which  operate  concurrent  with  sys¬ 
tem  operation.  They  include  maintenance/ 
diagnostic  programs  to  analyze  performance 
and  detect  or  isolate  faults  in  the  computer 
equipment.  Maintenance/diagnostic  prog¬ 
rams  can  be  developed  to  check  out  system 
equipment  not  normally  considered  integral 
to  the  computer  equipment,  for  example, 
interface/conversion  equipment  between  the 
computer  and  the  system  for  which  it  proces¬ 
ses  information. 

c.  Support.  Computer  programs  generally 
used  for  the  development  and  maintenance  of 
other  computer  programs.  Support  programs 
include  operating  systems,  assemblers,  com¬ 
pilers,  and  loaders.  For  example,  in  the  case  of 
training  devices,  these  programs  include  pre¬ 
flight  check  programs,  data  base  modification 
programs,  and  student  performance  data 
printout  programs. 

10-6.  Computer  Data.  Data  operated  on.  pro¬ 
duced  by,  or  otherwise  used  by  a  computer 
program.  Data  may  be  relatively  fixed,  such 
as  earth  coordinates  that  may  be  a  part  of  the 
system  data  base,  or  dynamic  such  as  mission 
data  that  may  be  unique  to  a  single  mission 
and  input  only  for  that  purpose.  All  data  must 
be  under  positive  control.  The  extent  and  na- 
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ture  of  this  control  will  depend  upon  usa^e. 
Mission  data,  such  as  target,  weapons  load, 
terrain  features,  must  he  under  the  control  of 
the  user.  Data  which  is  relatively  fixed,  and 
may  apply  to  the  entire  system  such  as  a  fleet 
of  aircraft,  or  interface  data  wttn  other  sys¬ 
tems  is  usually  controlled  at  the  system  level. 
Control  procedures  for  data  should  he  defined 
in  the  0/S  CMP. 

10-7.  Deficiency  Reporting. 

a.  To  provide  a  formalized  method  for  re¬ 
porting  deficiencies  in  computer  programs 
and  assure  correction  of  problems,  the  follow¬ 
ing  types  of  reports  are  authorized  for  use. 
Response  times  and  specific  channeling  of  re¬ 
ports  and  formats  for  these  reports,  both 
intra  and  intercommand,  will  he  identified  in 
the  O/S  CMP  in  accordance  with  TO  00-35 D- 
54  and  the  following  guidance. 

(1)  Emergency  Report.  This  report  deals 
with  problems  critical  to  mission  performance 
or  which  would  result  in  fatal  or  serious  in¬ 
jury  to  personnel.  This  report  will  be  certified 
as  mission  critical  and  transmitted  to  the  ap¬ 
propriate  responsible  authority  as  rapidly  as 
possible.  The  information  will  also  be  pro¬ 
vided  other  affected  users.  The  responsible 
authority  will  analyze  the  report,  determine 
the  impact,  and  furnish  disposition  to  all  af¬ 
fected  units  as  rapidly  as  possible. 

(2)  Routine  Report.  This  report  deals 
with  problems  of  a  noncritical  nature.  This 
report  should  be  submitted  to  the  appropriate 
responsible  authority.  The  responsible  au¬ 
thority  will  analyze  the  report,  determine 
possible  solutions  and  impacts  and  furnish 
disposition  to  all  affected  units. 

b.  The  basic  information  that  must  be 
submitted  when  reporting  a  deficiency  is  as 
follows: 

(1)  Identify  the  document  as  a  Deficiency 
Report. 

(2)  Date  submitted. 

(3)  Submitting  organization 

(4)  Computer  Program  Identification 
Number  and  other  nomenclature. 

(5)  Explanation  of  the  deficiency. 

(6)  Recommendations. 

(7)  Name,  grade,  phone  number  and  title 
of  the  action  officer. 

10-8.  Change  Reports.  All  proposed  changes 
will  be  documented  by  the  submitting  organi¬ 
zation  and  forwarded  to  the  appropriate  ap¬ 
proval  authority  in  accordance  with  the  pro¬ 
cedures  contained  in  the  O/S  rMP 


10-9.  \  &Y  of  Computer  Program*  in  the  De¬ 

ployment  Phase.  Inherent  in  the  updating  of 
eomputer  programs  is  the  necessity  to  insure 
that  adequate  testing  is  performed.  Planning 
and  procedures  for  computer  progiam  up¬ 
dates  will  include  testing  and  Y&Y  (chapter 
5). 

a.  Procedures  for  Y&Y  of  a  computer  prog¬ 
ram  are  distinctly  related  to  Us  type,  the 
magnitude  of  the  change  and  the  required 
degree  of  confidence  in  the  product  for  its  ap¬ 
plication.  System/nuclear  safety  must  he  con¬ 
sidered  in  determining  the  amount  of  Y&Y 
required. 

h.  Computer  programs  should  he  exercised 
through  a  predetermined  specified  range  of 
performance  prior  to  final  acceptance.  All 
changes  to  a  computer  program  require  Y&Y 
prior  to  computer  program  release  for  opera¬ 
tional  use. 

10-10.  Interservice  Support  of  Computer  Re¬ 
sources: 

a.  Existing  DOD  resources  will  he  used  to 
the  maximum  practical  extent.  When  compu¬ 
ter  resource  support  cannot  be  accomplished 
through  existing  Air  Force  capabilities,  other 
DOD  capabilities  should  be  considered  prior 
to  initiating  contractual  actions.  Life  cycle 
costs  will  be  considered  in  any  decision  for 
interservice  support  or  single  service  support. 

b.  Interservice  support  agreements  will  be 
prepared  by  the  supporting  organization  and 
approved  at  Major  Command  level.  These  ag¬ 
reements  will  detail  the  DOD  Service  respon¬ 
sible  for  the  performance  of  each  required 
function.  The  agreements  will  contain 
schedules,  organization,  procedures,  person¬ 
nel,  facilities,  and  funding  requirements  with 
a  delineation  of  the  resources  to  be  furnished 
by  each  Service. 

Cf  Cross  Servicing  agreements  financing 
will  be  determined  by  the  attaining  agency. 

d.  Host-tenant  agreements  will  be  gov 
erned  by  AFR  172-3/AR  37-19/SECNAVJST 
7020.4B. 

10-11.  Security  Assistai.ee  Program.  The 
general  policies  and  procedure*  for  Imple¬ 
menting  and  managing  approved  Grant  Aid/ 
Securing  Assistance  Service  Funded  prog¬ 
rams  and  Foreign  Military  Sales  are  in  AFR 
400-20,  AFR  5-16,  AFM  400-3,  AFR  800-18, 
and  AFM  67-1,  Volume  IX.  Security  regula¬ 
tions  in  connection  therewith  are  in  AFR 
205-1. 
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Acquisition  Management 

MANAGEMENT  OF  COMPUTER  RESOURCES  IN  SYSTEMS 
AFR  800-14,  vol  I,  12  September  1975,  is  supplemented  as  follows: 

1.  The  ASD  Weapon  System  Computer  Resource  Focal  Point,  ASD/EN,  will  resolve  questions  concerning 
the  applicability  of  AFR  800-14  at  the  ASD  level.  In  matters  that  relate  to  avionics  within  the  scope 
of  AFR  800-28  the  resolution  will  be  coordinated  with  ASD/AX.  The  focal  point  will  refer  questions 
or  conflicts  to  AFSC/XRF  if  further  resolution  is  required. 

3a(AFSC)  Sup).  Programs  not  subject  to  DSARC/AFSARC  reviews  will  accomplish  computer  resource 
requirements  reviews  before  release  of  full-scale  development  phase  solicitation  documents. 

3e(l)(AFSC  Sup).  Program  and  project  offices  will  coordinate  requests  for  waivers  (as  required  by 
AFR  300-10)  for  use  of  nonapproved  programming  languages  with  the  ASD  Weapon  System  Computer 
Resource  Focal  Point.  This  action  will  be  completed  as  early  as  possible  in  the  program  life  cycle, 
always  before  the  full-scale  development  solicitation. 

3i(l)(Added).  Solicitation  documents  will  include  statements  that  require  the  responder  to  identify 
and  cost  all  computer  resource  items.  ASPR  9-500  governs  requirements  for  rights  in  technical 
data  and  computer  software. 

3i(2)(Added).  Special  procedures  are  required  for  computer  programs  which  are  considered  for  release 
to  foreign  governments  or  to  foreign  nationals.  For  systems  having  computer  programs  which  are 
scheduled  for  foreign  release,  the  chairperson  of  the  Computer  Resource  Working  Group  (CRWG) 
will  consult  with  the  ASD  Foreign  Disclosure  Policy  Office,  ASD/XOP,  in  planning  that  release. 

3i(3)(Added).  Computer  Program  Development  Planning  (C.PDP)  information  will  be  solicited  during 
the  proposal  phase  of  the  contracting  process  where  computer  programs  are  to  be  developed.  This 
proposal  information  may  be  negotiated  and  made  part  of  the  contract. 

3m(4).  Computer  programs  which  contain  mission  parameters  and  mission  peculiar  data  will  be  designed 
in  such  a  way  that  the  mission  parameters  and  data  can  be  loaded/modified  without  affecting  the 
remainder  of  the  computer  program. 

3m(5).  The  Computer  Resources  Integrated  Support  Plan  (CRISP)  for  different  computer  programs 
within  a  system  such  as  operational  flight  programs  and  automated  test  equipment  computer  programs 
may  be  separate  volumes  for  ease  of  preparation.  The  CRISP  is  to  be  an  Air  Force  generated  document 
that  is  used  as  a  planning  tool  by  the  participating  Commands. 

5b(l)(AFSC  Sup).  ASD  maintains  an  organic  computer  resource  acquisition  support  capability.  The 
acquisition  support  capability  includes  organizations  in  avionics,  automated  test  equipment,  and 
simulator  disciplines  and  specialists  in  the  integration  and  utilization  of  computer  s'  stems  in  most 
distributed  application  areas.  Functional  responsibilities  for  computer  resources  within  ASD  are 
allocated  as  follows: 
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(a)  Computer  Center:  Responsible  for  the  maintenance  of  we; 
(assemblers,  compilers,  etc.)  when  ASD  organic  maintenance  is  determine 
Furnishes  technical  guidance  and  assists  in  the  formal  evaluation  and  proc 
Requirements  (DARs)  generated  by  users  cf  weapon  system  computer  resc 
Agency  Procurement  Requests  required  tc  obtain  Delegation  of  Procurem 
for  ADPE  items.  Participates  in  proposal  evaluation  of  weapon  system  su 

(b)  Configuration  Management:  Identifies  and  tracks  ail  comp 
items  to  a  sufficient  level  of  detail  to  enable  adequate  configuration  cont 
allocated  and  product  baselines,  modifies  these  baselines  through  configur 
and  maintains  status  of  the  current  approved  configuration.  Responsible  i 
tion  requirements  and  format.  Reviews  all  computer  resource  configurati 
management  of  their  compliance  with  the  contract. 

(c)  Comptroller:  Provides  techniques  and  procedures  for  estirr 
resource  costs  from  conceptual  through  the  operational  phases.  Determin 
systems  for  collection  and  evaluation  of  cost  related  data  and  validates  cc 
with  actual  data. 

(d)  Engineering:  Responsible  for  validation/coordination  of  te< 
preparation  of  specifications,  statements-of-work  and  other  engineering  d 
of  proposals  including  risk  and  suitability  determination  to  meet  the  techn 
technical  guidance  and  support  to  program  offices. 

(e)  Procurement:  Establishes  procurement  policy  and  furnishe 
and  assistance  in  all  phases  of  procurement  of  computer  resources. 

(f)  Program  Management:  Manages  acquisition  of  the  comput 
element  of  the  weapon  system.  Ensures  that  computer  resources  are  cove 
ment  Plan  (PMP).  Establishes  and  chairs  the  Computer  Resource  Working 
the  Computer  Resources  Integrated  Support  Plan  (CRISP).  Responsible  fo 
Computer  Program  Development  Plan  (CPDP). 

5b(l)(a)(AFSC  Sup).  The  ASD  Weapon  System  Computer  Resource  Focal  P 
office  of  the  ASD  Deputy  for  Engineering,  is  the  Product  Division  Focal  P 
the  focal  point  will  be  to  monitor  the  implementation  of  AFR  800-14  and  ' 
policies  arising  from  it.  For  matters  relating  to  avionics  within  the  scope 
will  be  compatible  with  the  Air  Force  Avionics  Master  Plan  implemented  1 
point  will  provide  a  liaison  between  ASD  and  higher  headquarters,  other  pr 
and  industry  in  matters  relating  to  weapon  system  computer  resource  polic 
cond!  ct  seminars  on  pertinent  aspects  of  computer  resource  technology  ar 
focal  point  will  interface  with  the  ASD  Automatic  Data  Processing  (ADP) 
involving  application  of  300  series  regulations. 

5d.  The  ASD  Weapon  System  Computer  Resource  Focal  Point  interfaces  v 
Center,  control  and  standardization  groups,  development  planning,  the  eng 
program  offices,  and  AFSC  laboratories  to  assist  in  assuring  the  timely  api 
computer  technology  into  systems. 


6hiAdded).  The  program  and  project  offices  will  identify  an  individual  wh< 
for  all  matters  pertaining  to  computer  resources  for  that  program  or  proje 


GEORGE  H.  SYLVESTE 
Commander 


.DC.  OEM  ANN 
■  t  Administration 


AF  REDFI.ATlo\ 


DEPARTMENT  OF  THE  AIR  FORCE 
Headquarters  VS  Air  Force 
Washington  DC  20330  15  I  -m l 


Data  Automation 

COMRl'TKR  PROGRAMMING  LANGl'AGES 

This  regulation  prescribes  policy  for  using  computer  programming  languages,  and  for  specify 
curement  and  testing  requirements  for  computer  programming  language  compiler-.  It  imp 
DOD  Directive  5100. 40,  August  1ft,  1975;  DOI)  Instruction  5000.29,  April  2*1,  1970;  DoD  In- 
7900. 1,  May  19,  1970;  and  DOD  Manual  4120.3-M.  January  1972. 


Objectives  . 

Applicability  . 

Definitions . 

Policy . 

Requirements . 

Compiler  Testing . 

Conversion . 

Designated  Control  Agents . 

Waivers . 

Publications  Distribution . . 

Responsibilities  . 

1.  Objectives.  Implementation  of  this  policy  pro¬ 
vides  Air  Eorce  computer  programming  language 
standards  to  enable  commanders  and  their  staffs 
to  improve  interchangeability  and  upward  com¬ 
patibility  of  computer  programs  within  and 
among  Air  Force  systems;  reduce  programming 
and  reprogramming  costs;  reduce  conversion  ef¬ 
forts  (luring  transition  from  one  computer  to 
another;  minimize  requirements  for  retraining  of 
computer  programmers;  and  ensure  that  stand¬ 
ard  computer  programming  language  compilers 
acquired  from  vendors  comply  with  the  Air  Force 
standard  specifications. 

2.  Applicability.  This  regulation  applies  to  all 
Air  Force  activities  using  or  planning  to  use  com¬ 
puter  programming  languages,  or  acquiring  com¬ 
puter  programming  language  compilers  for  cur¬ 
rent  and  future  ADS.  It  applies  to  all  requests  for 
and  use  of  computer  programming  languages  and 
associated  compilers  in  support  of  Air  Force  sys¬ 
tems,  whether  this  support  is  developed  in-house 
or  under  contract . 

3.  Definitions: 

a.  Assembly  Languages.  Machine  dependent, 
low  order  programming  languages  consisting  of 
symbolic  operation  codes  and  symbolic  ad 
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dresses.  Each  language  requires  an  as- 
which  translates  symbolic  operation  cod 
machine  operation  codes  and  symbolic  ad< 
into  absolute  or  relocatable  machine  addr 

b.  Basic  Software.  See  AFR  300-2. 

c.  Command  ADI*  Program  Single  Ma 
The  Director  of  Data  Automation  or  com] 
official  at  each  MAJCOM  SO  A  designated 
Commander  thereof.  Responsibilities 
Command  ADP  Program  Single  Manager 
tablished  by  AFR  300-2. 

(1.  Compiler  Testing.  The  operation  of 
puter  programming  language  compiler 
rigidly  controlled  data  base  and  a  selecte 
well-defined  computer  program.-  which 
standard  language  features,  such  that  the 
produced  from  the  exercise  can  be  co 
against  an  expected  set  of  answers  to  dot 
the  compiler's  compliance  with  the  la 
standard.  A  report  i-  prepared  at  the  on 
of  the  testing  exercise  which  summarize- 
sults  of  the  test-  including  a  composite  lis 
features  exercised  and  any  noted  di-crop 

e.  Computer  Program.  See  AFR  3iki  ; 

f.  Designated  Control  Agent.  The  Ai 
organization  responsible  for  as-uring  tin 
it y  and  configuration  of  an  Air  Force 
high  order  programming  language:  eii-ui 
correctness  of  testing  routine-  which  c 
the  correspondence  between  the  lallgUagt 
ard  and  compiler  implementations:  di-~cn 
available  aids  for  conversion  from  past  to 
version-  ot  a  language  standard,  and  e 
that  computer  programming  language  m 
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acquired  by  Air  Force  activitie.-,  comply  with  the 
-tandard  language  specification. 

g.  Data  Processing  Installation  (DPI)  Man¬ 
agers.  See  AFK  Mbit  2. 

h.  Federal  COBOL  Interpretations  Commit¬ 
tee.  The  committee,  established  and  chaired  by 
the  National  Bureau  of  Standards,  which  is  re¬ 
sponsible  for  the  uniform  interpretation  of  the 
Federal  (Air  Force)  COBOL  Standard. 

i.  FPMR.  Federal  Property  Management  Reg¬ 
ulations  issued  by  the  Ceneral  Services  Adminis¬ 
tration  ((ISA). 

j.  High  Order  Programming  Languages.  Pro¬ 
gramming  languages  (of  an  order  higher  than  as¬ 
sembly  languages),  designed  for  ease  of  expres¬ 
sion  of  a  class  of  problems  or  procedures  by  hu¬ 
mans  to  achieve  varying  degree's  of  machine  in¬ 
dependence.  These  languages  are  designed  for 
programming  convenience,  rather  than  for  easy 
generation  of  machine  code  instructions.  The  lan¬ 
guages  are  intended  as  a  means  for  directly  pre¬ 
senting  procedures  to  a  computer  for  which  a 
compiler  exists,  and  as  a  means  of  communicating 
such  procedures  among  individuals. 

k.  Specialized  High  Order  Programming 
Languages.  For  the  purpose  of  this  regulation, 
all  high  order  programming  languages,  except 
those  listed  in  paragraph  4c,  are  classified  as  spe¬ 
cialized  high  order  programming  languages. 

l.  Structured  Programming.  The  writing  of 
computer  programs  in  a  disciplined,  modular 
fashion,  such  that  the  overall  program  logic  is  de¬ 
signed  first,  and  each  major  component  is  de¬ 
signed  before  any  of  its  subcomponents.  Struc¬ 
tured  programming  uses  only  three  logic  struc¬ 
tures:  (l)a  simple  sequence  of  one  or  more  opera¬ 
tions:  (2)  a  conditional  execution  of  one  or  mon- 
operations  within  a  sequence:  and  CD  a  repetition 
of  one  or  more  operations  while  a  condition  is 
true.  A  logical  routine  within  a  structured  pro¬ 
gram  has  only  one  entry  point  and  one  exit 
point. 

m.  American  National  Standards  (ANSI. 

ANS  for  ADPK  and  computer  software  are  ap¬ 
proved  and  issued  periodically  by  the  American 
National  Standards  Institute  (ANSI)  X.'i  Stand¬ 
ards  Committee,  which  includes  membership  of 
the  Department  of  Defense,  '['he  ANSI  standards 
which  have  been  adopted  for  Air  Force  use  are 
published  in  the  DOD  Index  of  Specifications  and 
Standards. 

n.  Federal  Information  Processing  Stand¬ 
ards  (FIPS).  FIPS,  issued  by  the  National 
Bureau  of  Standards,  announce  the  adoption  and 
implementation  of  specific  computer  standards 
within  the  Federal  (lovernment. 

o.  The  CODASYL  COBOL  Journal  of  De¬ 
velopment.  The  complete  specification  of 
COBOL  elements  and  capabilities  which  ha  • 


been  approved  as  the  COBOL  language.  The  Air 
Force  COBOL  Standard  is  a  .-ubset  of  the  com¬ 
plete  language  contained  in  tl.F  Journal. 

1.  Policy: 

a.  The  ANSI  and  the  National  Bureau  of  Stand¬ 
ards  are  recognized  as  the  organizations  respon¬ 
sible  for  the  development  of  the  National  and 
Federal  computer  programming  language  specif¬ 
ication.-,  respectively,  which  have  been  adopted 
as  Air  Force  -tandards. 

h.  The  Programming  Language  Committee  of 
the  Conference  on  Data  Systems  Languages 
i CODASYL)  is  recognized  as  the  sole  Interna¬ 
tional  development  group  for  the  COBOL  lan¬ 
guage. 

c.  The  Air  Force  standard  high  order  pro¬ 
gramming  languages  are: 

ill  COBOL— as  defined  in  Federal  Informa¬ 
tion  Processing  Standards  Publication  (FIPS 
PCB)  21-1,  1  December  IDT.').  In  addition  to  the 
complete  set  of  language  capabilities,  three  sub¬ 
sets  are  identified  in  FIPS  PCB  21  1  which  may 
be  specified  and  used  as  data  processing  require¬ 
ments  dictate. 

(2)  FORTRAN— as  defined  by  American  Na¬ 
tional  Standards  X2.;i-l(ibh  or  X2.  lO-lfNiti. 

C{)  JOVIAL  (-Id) — as  defined  by  MII.-STD- 
1  :,HX  [  FSAF). 

(4)  -JOVIAL  (J72/I )  as  defined  by  M I L - 
STD- 1 ')S9  (FSAF). 

(f>)  PL/I — as  defined  by  American  National 
Standard  .X2.52-  197b. 

d.  I'se  of  standard  compilers  developed  in  ac¬ 
cordance  with  the  specifications  contained  in 
ANS  COBOL  XT 22- 1  libs'  will  continue  to  be  used 
in  current  !y  ope  rat  dmal  systems  until  the  present 
ADPK  is  replaced  or  until  a  requirement  exists 
that  dictates  procurement  of  a  new  COBOL  com 
piler  for  the  current  .ADPK. 

e.  The  use  of  specific  Air  Force  standard  high 
order  languages  in  Air  Force  systems  will  he 
based  on  the  capability  of  the  Language  to  meet 
the  system  requirements. 

f.  The  Air  Force  standard  programming  lan¬ 
guage  specifications  are  minimum  compile)'  spe¬ 
cifications  for  procurement  purpo.-t's.  Additional 
language  specifications  ma\  be  procured  and  used 
to  satisfy  programming  requirements  not  incor¬ 
porated  in  the  approved  standard  specification  in 
accordance  with  paragraph  2b. 

g.  Structured  programming  will  be  Used  to  the 
maximum  extent  possible  in  the  development  of 
Air  Force  >y stems. 

h.  An  Air  Force  standard  high  older  program 
ming  language  will  be  employed  in  all  fwtun  Air 
Force  >y>tellis  except  that: 

ip  Specialized  high  order  programming  lan 
gllages  ma\  be  u-ed  for  cP  -.-es  of  application.-. 


-A- 


^-~L  -V- 


1*4 


AFR  .500-10 


1.')  December  1970 


where,  for  technical  reasons,  the  list-  of  an  Air 
Force  standard  high  order  programming  lan¬ 
guage  would  not  he  feasihle.  These  languages 
must  he  specified  and  justified  in  accordance  with 
paragraphs  f>d  and  e,  and  approved  in  accordance 
with  paragraph  9. 

(2)  Assembly  languages  may  he  employed  for 
future  computer  programs  and  basic  software 
when  the  Air  Force  standard  high  order  pro 
gramming  languages  do  not  have  the  capability  to 
accomplish  required  functions  which  can  be  ac¬ 
complished  in  an  assembly  language,  and  where  it 
would  not  be  cost  beneficial  to  have  the 
capabilities  added  to  the  Air  Force  standard  high 
order  programming  language  compiler.  (NOTH: 
The  potential  costs  for  subsequent  reprogram¬ 
ming  of  these  programs  in  a  high  order  program¬ 
ming  language  must  be  considered  in  determining 
the  cost  benefits,  ratios,  and  effectiveness  to  jus¬ 
tify  the  use  of  an  assembly  language.) 

i.  Computer  programs  on  hand  that  are  coded 
in  an  assembly  language  should  be  converted  to  a 
high  order  language  if  the  programs  are  expected 
to  have  a  usefulness  extending  into  the  next  com¬ 
puter  replacement  period,  provided  operational 
requirements  would  make  such  conversion 
economically  and  technically  feasible.  If  cost  ef¬ 
fective,  such  program  conversion  should  be  ac¬ 
complished  during  program  modification  or 
maintenance. 

j.  Use  of  implementor-defined  features  and 
vendor  supplied  nonstandard  extensions  in  high 
order  programming  language  compilers  will  be 
avoided  when  there  is  a  probability  that  the  ADS 
being  developed  will  be  additionally  operated 
upon,  or  converted  for  use  with,  new  or  different 
computer  systems. 

k.  Retrieval  systems  and  associated  special 
purpose  retrieval  languages  will  not  be  used  for 
recurring  RCK  reports.  Such  systems  and  lan¬ 
guages  may  be  used  to  fulfill  only  the  require¬ 
ments  for  one-time  reports  unless  approval  for 
retrieval  use  on  recurring  non-RCS  reports  is  ob¬ 
tained  from  the  appropriate  Command  ADR  Pro¬ 
gram  Single  Manager.  This  approval  authority 
may  be  delegated  to  the  DPI  Manager  as  appro¬ 
priate.  Caution  must  be  exercised  in  approving 
Use  of  retrieval  systems  written  in  programming 
languages  other  than  COROD,  FORTRAN,  JO¬ 
VIAL  or  PL/I  for  recurring  reports  since  Air 
Force  system  compatibility  and  interchangeabil¬ 
ity  will  be  seriously  jeopardized  when  subsequent 
action  is  taken  to  replace  or  upgrade  current 
computer  equipment . 

5.  Requirements: 

a.  Air  Force  standard  high  order  computer 
programming  language  requirements  submitted 
under  any  directive,  plan,  or  program  will  be 


processed  through  established  channels  for  re¬ 
view  and  approval. 

<  1 )  COBOL  specifications  will  reference 
JII’S  I'l  B  Jl-I,  1  I)(  n  nih,  i-  197.1,  when  the 
complete  set  of  capabilities  of  the  Air  Force 
Standard  C< )R()L  is  required.  When  less  than  the 
complete  set  of  capabilities  of  the  Air  Force 
standard  is  required,  specifications  will  cite  the 
specific  subset,  as  reflected  in  FIPS  Pl’R  21-1. 
For  example,  if  only  the  minimum  COROL  capa¬ 
bility  is  desired,  the  citation  would  be  "Low 
Level  Subset,  FIPS  PFR  21-1.  1  December 
197.').'' 

<2)  FORTRAN  specifications  will  reference 
American  Sat, mini  Standard  FORTRAX 
X-i.H-HKit:  if  the  complete  set  of  capabilities  of 
the  Air  Force  Standard  FORTRAN  is  required. 
When  less  than  the  complete  FORTRAN  capabil¬ 
ity  is  required,  American  Xatiunal  Standard 
Basic  F< tRTRAX  A’./. ln-ium;  will  be  cited. 

<•’{>  JOVIAL  (.Id)  specifications  will  reference 
Mll.-STD-1.1M  trSAF). 

(  i)  .JOVIAL  (J7M/I)  specifications  will  refer¬ 
ence  MU. -STD- List)  t('SAF). 

(.">)  PL  1  specifications  will  reference  Ameri¬ 
can  Xatiunal  Standard  F rof/ra m m i a;/  La  mjnaqc 
FLU  Xd.. Id -1970. 

b.  The  specification  of  required  capabilities,  in 
addition  to  those  contained  in  the  Air  Force 
standard  specification,  is  permissible.  Such  ex¬ 
tended  capabilities  will  be  coordinated  with  t hi* 
Designated  Control  Agent  prior  to  submission  as 
part  of  the  specification.  These  extended 
capabilities  will  be  specified  in  the  following 
mantle  r. 

(1)  COROL: 

(a)  Capabilities  consisting  of  elements 
which  are  contained  in  the  latest  edition  of  the 
CODAS)  I,  COBOL  .Journal  ul  Dccclu/nncnt  will 
be  specified  by  page  number  and  issuance  date  of 
that  edition. 

(b)  Capabilities  consisting  of  elements 
which  are  not  contained  in  the  CODASYL 
COBOL  .Journal  at  I)crcluf>mi  nt  will  include 
explicit  syntactic  and  semantic  definitions  of  the 
desired  language  (dements. 

(2)  Specification  for  additional  capabilities 
for  all  other  Air  Force  standard  high  order  pro¬ 
gramming  languages  will  contain  explicit  defini¬ 
tion  (d’the  required  language  elements. 

(Ml  Justification  for  the  use  of  all  additional 
capabilities  will  be  submitted  as  part  of  the  spe- 
cificat  ion. 

c.  The  language  specifications  described  above, 
including  approved  additional  capabilities,  are 
established  as  th(  minimum  specifications  for 
procurement  purposes.  Vendors  will  not  be 
penalized  for  proposing  compilers  which  contain 
(dements  above  a  required  Air  Force  standard 
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language  specification,  provided  these  elements 
are  furnished  without  additional  cost  and  do  not 
impose  any  additional  processing  burden  by  their 
inclusion.  Caution  must  be  exercised  when  using 
these  additional  features  as  outlined  in  paragraph 

4j. 

d.  The  specification  of  capabilities  required  for 
specialized  high  order  programming  languages 
will  contain  either  the  complete  list  of  required 
language  elements,  including  syntactic  and 
semantic  features  as  well  as  functional  and  tech¬ 
nical  characteristics,  or  a  reference  to  a 
documented  language  specification  which  con¬ 
tains  the  required  facilities. 

e.  Justification  will  be  submitted  with  the  spe¬ 
cifications  for  the  proposed  use  of  asst  mbly  lan¬ 
guage  or  a  specialized  high  order  programming 
language,  as  specified  in  paragraph  9. 

6.  Compiler  Testing: 

a.  All  COBOL  compilers  will  be  tested  in  ac¬ 
cordance  with  FPMR  1 0 1—32. 1 305—  1  to  ensure 
their  compliance  with  the  Air  Force  COBOL 
Standard  prior  to  acceptance  of  the  compiler  for 
Air  Force  use. 

b.  All  JOVIAL  compilers  will  be  tested  by  Air 
Force  Systems  Command,  using  the  documenta¬ 
tion  procedures  outlined  in  FPMR  101-32. 1  305- 
1,  to  ensure  their  compliance  with  the  Air  Force 
JOVIAL  Standard  prior  to  acceptance  of  the 
compiler  for  Air  Force  use. 

c.  The  Air  Force  activity  conducting  the  pro¬ 
curement  and  the  user  of  the  proposed  system 
have  final  authority  to  determine  whether  the 
tested  compiler  is  acceptable  to  the  user. 

d.  Compiler  testing  systems  for  other  Air 
Force  standard  high  order  programming  lan¬ 
guages  will  be  used  as  they  become  available  to 
verify  conformance  to  the  respective  Air  Force 
standard  specifications  prior  to  acceptance  of  the 
compiler  for  Air  Force  use. 

7.  Conversion: 

a.  FIPS  PUB  43  is  an  aid  in  the  transitioning  of 
COBOL  programs  from  use  with  compilers  de¬ 
veloped  in  accordance  with  the  previous  Air 
Force  COBOL  Standard  specifications  contained 
in  ANS  X3. 23-1968  to  compilers  developed  in  ac¬ 
cordance  with  FIPS  PUB  21-1. 

b.  As  other  Air  Force  standard  high  order  pro¬ 
gramming  language  specifications  are  revised, 
conversion  aids  will  be  provided. 

8.  Designated  Control  Agents.  Each  of  the  Air 
Force  standard  high  order  programming  lan¬ 
guages  has  an  Air  Force  Designated  Control 
Agent  established,  as  follows: 

a.  Air  Force  Systems  Command  is  the  Desig¬ 
nated  Control  Agent  for  JOVIAL  specifications. 


b,  HQ  1  SAT  KRAX  is  the  Designated  ( 'otitrol 
Agent  for  COBOL,  FOR  TRAN',  and  PI.  I  'peed 
Rations. 

9.  Waivers: 

a.  Requests  for  waiver  for  procurement  of  as¬ 
sembly  language  or  specialized  high  older  pro¬ 
gramming  language  compilers  will  be  submitted 
to  HQ  USAF  for  approval  prior  to  acquisition. 

b.  Requests  for  use  of  assembly  language  or  a 
specialized  high  order  programming  language  for 
any  purpose  other  than  that  specified  in  the 
waiver  described  in  paragraph  9a  will  be  sub¬ 
mitted  to  HQ  USAF  for  approval  prior  to  use. 
The  approval  will  specify  the  extent  to  which  the 
assembly  language  or  specialized  high  order  pro¬ 
gramming  language  may  be  used. 

c.  New  waivers  are  not  required  for  the  pre¬ 
viously  approved  use  of  assembly  language  or  a 
specialized  high  order  programming  language  for 
those  Air  Force  ADS  which  were  operational  or 
under  development  as  of  the  date  of  this  regula¬ 
tion.  If  use  is  extended  to  other  ADS  in  the  fu¬ 
ture.  the  waiver  procedures  in  paragraphs  9a  and 
9b  will  be  applied. 

10.  Publications  Distribution: 

a.  The  following  publications  may  be  obtained 
free  of  charge  through  normal  Air  Force  channels 
for  distribution  of  computer  standards  documents 
by  contacting  the  Naval  Publications  and  Forms 
Center,  5801  Tabor  Avenue,  Philadelphia  PA 
19120. 

(1)  American  National  Standard  Program¬ 
ming  Language  PL/I,  X3. 53-1976. 

(2)  American  National  Standard  FOR¬ 
TRAN.  X3.9-1966. 

(3)  American  National  Standard  Basic 
FORTRAN.  X3. 10-1966. 

(4)  FIPS  PUB  21-1,  COBOL. 

(5)  FIPS  PUB  29,  Interpretation  Proce¬ 
dures  for  Federal  Standard  COBOL. 

(6)  T  IPS  PUB  43.  Aids  for  COBOL  Program 
Conversion. 

(7)  MIL-STD-1588  (USAF),  JOVIAL  J3. 

(8)  M I L-STD- 1589  (USAF),  JOVIAL  J 73 H. 

b.  The  CODASYL  COBOL  Journal  of  De¬ 
velopment  may  be  obtained  at  a  cost  from  the 
Technical  Services  Branch.  Department  of  Sup¬ 
ply  and  Services.  5th  Floor,  88  Metcalfe  Street. 
Ottawa,  Ontario,  Canada  KlA  OS5. 

1 1 .  Responsibilities: 

a.  HQ  USAF: 

(1)  The  Director  of  Data  Automation  (AF 
KRA): 

(a)  Serves  as  the  Air  Force  manager  for 
the  use,  standardization,  and  further  develop- 
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ment  of  computer  programming  languages  in  Air 
Force  systems. 

(b)  Serves  as  the  Air  Force  Designated 
Control  Agent  for  the  Air  Force  Standard 
COBOL,  FORTRAN,  and  PI.  I  programming 
languages. 

(c)  Coordinates  Air  Force  participation  in 
computer  programming  language  development 
and  standardization  activities,  compiler  testing 
systems  development  and  maintenance,  and 
computer  program  conversion  aid  activities 
among  the  Air  Staff  agencies  involved,  the  mili¬ 
tary  services  and  other  components  of  the  De¬ 
partment  of  Defense,  and  within  Federal  and  Na¬ 
tional  organizations. 

( (i )  Develops  and  promulgates  the  Air 
Force  policy  on  the  use  of  computer  programming 
languages,  including  use  of  validation  routines, 
conversion  aids,  and  other  related  language  tools. 

(e)  Develops  the  Air  Force  position  on  the 
acceptability  of  draft  National  and  Federal 
standard  programming  language  specifications, 
in  coordination  with  interested  major  commands, 
separate  operating  agencies,  and  elements  of  HQ 
FSAF. 

(f)  Provides  DOD  participation  in  the  plan¬ 
ning  and  policy  councils  of  the  ANSI  and  the 
Federal  Standards  committees  to  ensure  that 
timely  revision  of  those  programming  language 
standards  derived  from  National  and  Federal 
specifications  is  undertaken  and  completed,  as 
required  to  meet  Air  Force  needs;  and  to  ensure 
that  standard  specifications  are  expeditiously 
developed  for  those  nonstandard  programming 
languages  which  are  of  special  interest  to  the  Ait- 
Force. 

(g)  Provides  Air  Force  participation  on  the 
(’OI)ASVL  Programming  Language  Committee 
to  ensure  the  continuing  growth  of  the  COBOL 
programming  language  in  areas  where  Air  Force 
needs  are  not  currently  being  met. 

(h)  Provides  Air  Force  participation  on  the 
Federal  COBOL  Interpretations  Committee  and 
Federal  COBOL  Standards  Task  Croup  !»,  and 
coordinates  such  participation  among  the  Ait- 
Staff  agencies,  the  military  services,  and  other 
DOD  components. 

(2)  HQ  FSAF  Staff  Offices.  Within  their 
functional  areas  of  responsibility,  these  offices 
will  ensure  that  high  order  computer  program¬ 
ming  languages  and  assembly  languages  are  jus¬ 
tified  and  utilized  according  to  the  provisions 
contained  herein  and  in  coordination  with  HQ 
FSAF  Air  Staff  offices  concerned. 

b.  Major  Commands  and  Separate  Operating 
Agencies: 

(1)  Ensure  that  high  order  computer  pro¬ 
gramming  languages  and  assembly  languages  are 
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justified  and  utilized  according  to  the  provisions 
of  this  regulation. 

<2i  Ensure  that  specifications  for  computer 
programming  languages  submitted  under  any  di¬ 
rective,  plan,  or  program  are  in  accordance  with 
this  regulation. 

(Ml  Review  and  evaluate  proposed  language 
specifications  and  justifications  at  command  or 
agency  level  before  forwarding  them  through  es¬ 
tablished  channels. 

(1)  Provide  technically  qualified  participants 
for  computer  programming  language  develop¬ 
ment  and  standardization  activities,  as  directed 
by  HQ  FSAF. 

(oi  Establish  and  maintain  publication  dis¬ 
tribution  requirements  for  Air  Force  standard 
high  order  programming  language  specifications 
and  the  latest  edition  of  CODASYL  COBOL 
Journal  of  Development,  referenced  herein. 

Mi)  Forward  to  the  Air  Force  Designated 
Control  Agent,  through  command  channels, 
suggestions  on  new  or  existing  capabilities  for 
Air  Force  standard  high  order  computer  pro¬ 
gramming  languages,  and  all  questions  that  arise 
regarding  the  meaning  of  standard  language  spe¬ 
cifications. 

c.  Air  Force  Systems  Command.  In  addition 
to  the  responsibilities  included  in  paragraph  lib, 
the  Air  Force  Systems  Command  will  serve  as 
the  Air  Force  Designated  Control  Agent  for  the 
Air  Force  Standard  .JOVIAL  programming  lan¬ 
guage. 

d.  Air  Force  Designated  Control  Agents. 

Within  their  assigned  areas  of  control,  Desig¬ 
nated  Control  Agents  will: 

(1)  Ensure  that  compiler  testing  routines 
are  developed  and  maintained  to  satisfy  compiler 
testing  requirements  for  Air  Force  standard  pro¬ 
gramming  language  compilers. 

(2)  Ensure  that  M I L-STD- 15SM FSA F)  (JO¬ 
VIAL  JM)  and  MIL-STD-1.7WI  (FSAF)  (JOVIAL 
J7M/I)  are  developed  and  maintained  in  a  current 
status. 

(M)  Ensure  that  the  most  recent  compiler 
testing  routines  are  available  to  computer  man¬ 
ufacturers. 

(-0  Ensure  that  the  Air  Force  major  com¬ 
mands.  separate  operating  agencies,  and  HQ 
FSAF  Air  Staff  offices  are  notified  of  changes  in 
Air  Force  standard  high  order  programming  lan¬ 
guage  specification.',  changes  in  compiler  testing 
routines,  and  aids  lbr  program  conversion  from 
[last  to  current  standard  specifications  as  they 
become  available  or  are  adopted. 

(•'))  Ensure  that  all  questions  received  re¬ 
garding  the  meaning  of  current  language  specif¬ 
ications  are  satisfied.  All  requests  for  interpreta¬ 
tion  of  COBOL  w  ill  be  processed  in  accordance 
with  the  provisions  of  FIRS  RFB  29. 
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BY  ORDER  OF  THE  SECRETARY  OF  THE  AIR  FORCE 

OFFICIAL  DAVID  C.  JONES,  Oeneral.  I  SAI 

Chief  <>f  Staff 

JAMES  J.  SHEPARD,  Colonel,  USAF 
Director  of  Administration 

SUMMARY  OF  REVISED,  DELETED,  OR  ADDED  MATERIAL 

This  revision  deletes  the  requirement  to  restrict  the  use  of  COBOL,  FORTRAN  and  JOVIAL  to  cer¬ 
tain  types  of  computer  applications;  revises  the  Air  Force  COBOL  and  JOVIAL  standards;  adds  PL/I 
as  an  Air  Force  Standard  programming  language;  provides  revised  guidance  on  procurement  and  use  of 
computer  programming  languages;  adds  policy  on  use  of  structured  programming,  retrieval  systems 
and  retrieval  languages;  revises  policy  for  testing  programming  language  compilers;  assigns  Desig¬ 
nated  Control  Agents  for  each  Air  Force  Standard  programming  language;  and  revises  responsibilities 
for  policy  implementation. 


\FSt:  SUPPLEMENT  1 
AFR  300-10 
2  September  1980 

Data  Automation 

COMPUTER  PROGRAMMING  LANGUAGE 


DEPARTMENT  OF  THE  AIR  FORCE 
Headquarters  Air  Force  Systems  Command 
Andrews  Air  Force  Base,  DC  20334 


AFR  300-10,  15  Dec  76,  is  supplemented  as  follows: 

2.  This  supplement  applies  to  AFSC  ac  tivities  using  or 
planning  to  use  computer  programming  languages  for 
systems  managed  under  either  300-  or  800-series 
regulations.  Process  actions  that  affect  systems  managed 
under  300-series  regulations  through  the  ADP  Program 
Single  Manager  Refer  questions  or  conflicts  about  the  ap¬ 
plicability  of  this  regulation  to  HQ  AFSC/XRF  for 
resolution. 

3p(Added).  JOVIAL  Language  Control  Agent.  The 

organization  responsible  to  the  JOVIAL  Designated  Con¬ 
trol  Agent  for  ensuring  stability  and  configuration  of  the 
JOVIAL  standard  high  order  programming  language  J73. 
The  JOVIAL  Language  Control  Agent  controls  changes  to 
the  language  standard.  Ensures  changes  are  reviewed  by 
the  AFSC  Product  Division,  Laboratory,  and  other 
language  focal  points. 

3q( Added).  Language  Focal  Point.  Includes  represent¬ 
atives  from  various  DOD  agencies,  other  MAJCOMs,  and 
the  following  AFSC  organizations:  ASD,  ESD,  SD,  AD, 
BMO,  RADC,  AFWAL,  and  AFATL.  The  Language  Focal 
Point  will  ensure  communication  between  the  parent 
organization  and  other  organizational  elements  of  the 
language  control  structure. 

3r(Added).  JOVIAL  Language  User.  Any  person  or 
organization  (DOD  or  otherwise)  that  uses  or  plans  to  use 
JOVIAL  (J73). 

3s(Added).  JOVIAL  Language  Control  Facility.  A  serv¬ 
ice  organization  established  by  the  JOVIAL  Language 
Control  Agent  to  perform  the  functions  listed  in  paragraph 
llc(l)  of  this  supplement 

3t( Added).  JOVIAL  User’s  Group.  A  working  group  that 
provides  a  forum  for  discussing  language  issues;  provides 
inputs  to  the  Language  Control  Facility  and  Language 
Control  Board  on  language  changes  or  subsets,  user  ex¬ 
perience  with  the  language,  compilers,  and  other  support 
tcx>ls.  Reviews  and  comments  on  proposed  revisions  to  the 
language  standard  made  by  the  Language  Control  Facility. 


Supersedes  AFR  300-10/AFSC  Sup  I.  14  Dec  78 

No.  of  Printed  Pages:  3 

OPR  XRF  (Maj  A  H  Kopp) 

Approved  by.  Col  H  P  Wheeler.  Jr 
Editor  Tina  DiNapoli 
Distribution:  F;  X 
HQ  USAF/ACDX 


3u(Added).  JOVIAL  Language  Control  Board.  An 

organ iza* ion  established  |omth  bv  iheJOV  IAL  Language 
Control  Agent  and  the  JOVIAL  Designated  Control  Agent 
to  assist  m  making  JOVIAL  language  control  and  policy 
decisions  Its  primarv  r esponsibihtv  is  to  review  and  recom¬ 
mend  proposed  changes  to  the  JO\  IAL  language  standard 
and  policy  on  a  quarierK  basis.  It  is  chaired  by  the 
JOVIAL  Language  Control  Agent  and  is  c  um|xised  of  the 
Designated  Control  Agent  the  language  focal  [toints  and 
representatives  Irom  other  selected  DOD  organizations. 
The  Designated  Control  Agent  or  Language  Control  Agent 
may  invite  representatives  from  organizations  outside  of 
DOD  to  participate 

3v(Added).  IEEE  ATLAS  Committee.  An  international 
committee  established  under  the  Institute  of  Electrical  and 
Electronic  Engineers  (IEEE)  to  develop  and  standardize 
the  Abbreviated  Lest  Language  for  all  Systems  (ALLAS) 
This  group  reviews  and  approves  all  c  hanges  to  ATLAS 
and  controls  its  configuration  baseline  It  consists  of  a 
steering  committee  and  eight  tec  hnical  working  groups. 

3w(Added).  ATLAS  Language  Control  Agent.  The 

organization  res|x>nsible  to  the  Air  Force  Designated  Con¬ 
trol  Agent  for  the  compliance,  stability,  and  configuration 
of  ATl^AS  as  used  w  ithin  AFSC  I  he  A I  LAS  Control 
Agent  ensures  AFSC  Product  Divisions  and  laboratory- 
language  focal  points  review  changes. 

3x(Added).  ATLAS  Language  Focal  Points.  The  AFSC 
organizational  representatives  that  are  responsible  for  en¬ 
suring  compliance  to  IEF.E  STD  416  and  for  cexirdinating 
ATI.AS  c  hanges.  Fcxal  |x>ints  ensure  communication  be¬ 
tween  the  parent  organization  and  other  organizational 
elements  of  the  language  control  structure  and  include 
representatives  from  ASD.  ESD.  SD.  AD,  BMO.  RADC. 
AFW'AL.  and  AFA  TL 

3y(Added).  ATLAS  Language  Control  Facility.  A  serv¬ 
ice  organization  established  by  the  A  I  LAS  Language 
Control  Agent  to  [x-rform  the  functions  listed  in  paragraph 
1  lc(l)  of  this  supplement. 

3z(Added).  ATLAS  Language  User.  Any  px-rson  or 
organization  that  uses  or  plans  to  use  ATLAS 

3aa(Added).  DOD  ATE  Language  Standardization 
Committee  (DALSCOM).  The  DOD  organization 
res|x>nsible  for  the  configuration  of  A  TLAS  as  used  within 
the  Services  The  organization  reviews  and  approves  all 
DOD  proposed  A  TLAS  c  hanges  that  are  presented  to  the 
IEEE  ATI -AS  (  '.ommittee 


4c(4)  In  the  absenc  e  of  cornjx’lling  justific -ation  n>  tlu  mil- 
1  trary,  use  J73  on  all  Air  Forc  e  embedded  computer  sv stems 
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until  the  DOD-wide  standard  Ada  programming  language 
becomes  available.  ThisJ73  policy  does  not  pertain  to  soft¬ 
ware  supporting  ADP  resources  in  general  purpose  ADPS, 
developed,  acquired,  and  managed  by  the  AFR  300-series 
regulations  and  manuals  (defined  as  category  D  in  attach¬ 
ment  4  to  AFR  300-2).  However,  in  those  software  systems 
that  interface  with  or  are  in  direct  support  of  development, 
test,  or  support  of  weapon  systems,  selection  of  a  language 
will  be  guided  byJ73  policy.  General  purpose  computers 
acquired  by  SPOs  or  project  offices  under  AFR  300-12  for 
inclusion  in  a  weapon  system  are  part  of  the  system  and 
must  use  J73  unless  compelling  justification  is  furnished. 
When  compelling  reasons  justify  using  an  HOL  other  than 
1 73,  process  a  waiver  request  according  to  paragraph  9a. 

4c(5)  PI V I  is  not  approved  for  use  in  systems  managed  un¬ 
der  AFR  800-2  and  those  advanced  development  and 
prototype  demonstration  systems  that  will  change  to  AFR 
800-series  management. 

4e.  JOVIAL  (J73)  is  the  required  language  for  development 
in  Air  Force  aircraft  avionics  real-time  applications. 
Neither  COBOL,  ATLAS,  nor  FORTRAN  may  be  used 
for  on-board  operational  avionics  real-time  applications 
without  a  previously  approved  waiver.  The  Deputy  for 
Avionics  Control  (ASD/AX)  will  ensure  the  use  of 
JOVIAL  J73  in  all  aircraft  avionics  real-time  applications. 

4f.  Preprocessor  input  languages,  machine-oriented 
languages  and  subsets  or  supersets  of  standard  program¬ 
ming  languages  other  than  those  defined  in  paragraph 
5a(l)  and  (2)  and  ATLAS  will  be  treated  as  nonapproved 
languages  and  require  a  waiver  before  acquisition.  The  use 
of  preprocessors  to  implement  structured  programming 
constructs  is  considered  undesirable 

4h(l)  ATI  AS  is  an  approved,  specialized  high  order 
programming  language  for  automatic  test  equipment  ap¬ 
plications  only.  ATLAS  is  defined  by  three  IEEE  ATLAS 
standards:  IEEE  STD-416-I978-ATLAS  Test  Language, 
IEEE  STD-4 16A-1 978-ATI AS  Syntax,  and  IEEE  STD- 
771 -1979-ATLAS  User’s  Guide 

5a(6)(Added).  ATLAS  specifications  will  reference  the 
three  IEEE  ATIAS  standards  cited  in  paragraph  4h(l)  or 
their  official  successors.  Each  organization  cited  in 
paragraph  3x  will  establish  an  ATLAS  Language  Focal 
Point  for  their  organization 

5a(7)(Added).  JOVIAL  (J73)  specifications  will  reference 
MIL-STD-1589A  (USAF)  or  official  successors.  Each 
organization  cited  in  paragraph  3q  will  establish  a 
Language  Focal  Point  for  JOVIAL  (J73).  One  person  can 
act  as  an  ATIAS  Language  Focal  Point  and  a  Language 
Focal  Point  for  JOVIAL  (J73)  at  the  same  time. 

5b.  Obtain  a  waiver  from  the  Designated  Control  Agent  for 
using  extensions  to  standard  JOVIAL  and  ATLAS 
language  versions  before  submitting  as  p>art  of  the 
acquisition  specification.  Send  waiver  requests  according  to 
paragraph  9a. 

5c.  Process  extensions  to  JOVIAL  and  ATLAS  languages 


according  to  b  above.  Requests  for  extensions  will  receive 
prompt  attention  to  minimize  system  schedule  or  cost 
impacts. 

6b.  Submit  JOVIAL  compileis  for  each  separate  Air  Fort  e 
application  through  theJOVlAL  Language  Control  Agent 
to  the  Language  Control  Facility  for  validation  testing. 
JOVIAL  compilers  will  not  be  accepted  without  a  com¬ 
pleted  validation  test  reptort  Compilers  will  not  be  used  for 
fielded  applications  software  until  the  compiler  passes  the 
validation  acceptance  test. 

8c(Added).  HQ  AFSC/XRF  is  the  AFSC  designated  con¬ 
trol  agent  for  JOVIAL  (J 73 ).  HQ  AFSC/SDDL  is  the 
designated  control  agent  for  the  approved  specialized  high 
order  programming  language,  ATLAS. 

9a.  Send  requests  for  waiver  to  the  appropriate  designated 
control  ag-nt  through  the  language  focal  ptoints  for  AFR 
800-series  applications  or  through  the  ADP  Program  Single 
Manager  for  AFR  300-series  applications.  Send  infor¬ 
mation  copies  of  all  requests  to  the  Language  Control 
Agent  Waiver  requests  will  receive  prompt  attention  to 
minimize  system  schedule  or  cost  impacts.  Justification 
based  on  life  cycle  cost  savings  and  language  technical 
characteristics  must  accompiany  requests  for  waiver.  The 
justification  will  include  a  comparison  of  the  selected 
language  or  compiler  against  the  standard  languages.  The 
justification,  as  a  minimum,  will  address: 

( 1 )  Direct  development  cost  of  compiler  and  support 
software. 

(2)  Compiler  and  support  software  delivery  schedules 
and  the  impact  in  system  schedule. 

(3)  Commonality  of  the  selected  language  with 
languages  used  to  implement  existing  software  within  the 
system. 

(4)  Commonality  of  the  selected  language  with 
existing  and  new  development  software  on  other  systems 
that  interface  with  the  system. 

(5)  Suppjort  concepts  and  relative  supptort  cost  over  the 
system  life  cycle  for  each  of  the  languages  being  compared. 

(6)  Technical  deficiencies  of  the  languages  being  com¬ 
pared  that  affect  the  language  decisior 

(7)  Changes  required  to  the  existing  language 
definition  to  meet  the  system  requirements. 

(8)  Direct  and  indirect  contractor  cost  associated  with 
language  application  (for  example,  training,  subcontractor 
cost). 

(9)  Programming  languages  and  supptort  tools  used  to 
develop  and  maintain  the  support  software. 

9b.  Use  of  assembly  language  in  subsegments  of  a  com¬ 
puter  program  where  an  approved  HOL  is  used  does  not 
require  a  waiver.  Product  divisions,  centers,  and  separate 
operating  agencies  will  establish  guidance  for  use  of  assem¬ 
bly  language  in  applications  within  their  control. 

lOc(Added).  Obtain  specifications  for  the  ATLAS 
language  by  contacting  HQ  AFSC/SDDL 

I  lb(4)  AD/KR  will  represent  Air  Force  on  the  ANSI  X3J3 
FORTRAN  Standard  Development  Committee.  HQ 
AFSC/SDDL  and  Air  Force  designated  members  to  the 
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DALSCOM  Technical  Advisors-  Group  will  represent  the 
Air  Force  on  the  IEEE  ATLAS  Committee 

1 1  c(  1 )( Added).  HQ  AFSC/XRF  is  the  designated  control 
agent  for  JOVIAL  (J73).  Control  of  JOVIAL  (J73)  will  be 
executed  through  the  JOVIAL.  Language  Control  Agent 
The  Language  Control  Agent  will  transition  from  RADC 
to  ASD/AX  in  FY  81.  The  Language  Control  Facility  will 
transition  in  FY  81  from  RADC  to  ASD/AD  The 
Language  Control  Agent  will  task  the  Language  Control 
Facility  with  the  performance  of  the  following  control  func¬ 
tions  for  JOVIAL  (J73): 

(1)  Maintain  the  approved  baseline  language 
specification  MIL-STD-I589A  and  official  successors. 
Process  changes  to  the  specification  according  to  DOD 
4120-3M. 

(2)  Provide  for  distribution  of  the  language 
specification  to  language  focal  points  and  user  repre¬ 
sentatives. 

(3)  Test  each  compiler  for  adherence  to  the  standard 
language  specification  before  acceptance  of  the  compiler 
for  Air  Force  use.  Identify  extensions  that  have  been  im¬ 
plemented  in  the  compiler  and  recommend  to  the  user  on 
acceptance  of  the  compiler. 

(4)  Provide  technical  advice  to  the  users. 

(5)  Maintain  a  directory  and  inventory  of  compilers 
and  support  tools  for  JOVIAL  (J73).  Distribute  the  direc¬ 
tory  to  language  focal  points. 

(6)  Develop  and  maintain  operating  procedures  for  the 
JOVIAL  language  policy  and  control  process. 

(7)  Serve  as  office  of  record  for  JOVIAL  User’s  Group 
activities. 

(8)  Maintain  and  enhance  selected  JOVIAL  tools. 


i9i  Correct  and  enhance  selei  ted  JOVIAL  compilers 
and  <  ode  generators 

1 1  ct  2 )( Added i  HQ  AFSG  SDDL  is  the  Air  Fori  e 
Designated  Control  Agent  for  ATLAS  Control  of  ATLAS 
languages  will  be  exei  uted  through  the  ATLAS  Language 
Control  Agent.  ASD/AEG  is  the  ATLAS  Language  Control 
Agent.  Functional  areas,  or  organizations  within  a  func¬ 
tional  area,  mas  implement  additional  controls  within  their 
area  of  responsibility  The  ATLAS  Language  Control 
Agency  will  [serform  the  following  control  functions 

(1)  Review  and  coordinate  proposed  ATLAS  changes 
and  waivers.  Send  changes  and  waivers  to  the  Designated 
Control  Agents 

(2)  Provide  for  distribution  ol  AI  LAS  standards  and 
implementation  guidelines  to  language  final  points  and 
ATLAS  language  user 

(3)  Test  compiler  for  adherence  to  the  standard 
language  before  acceptanc  e  of  the  compiler  for  Air  Force 
use  Identify  extensions  that  have  been  implemented  in  the 
compiler  and  recommend  to  the  user  on  acceptance  of  the 
compiler 

(41  Provide  technical  advice  to  the  users. 

(5)  Maintain  a  directory  and  inventory  of  compilers 
and  support  tools  for  the  standard  languages. 

(6)  Develop  and  maintain  operating  procedures  for 
ATLAS  language  policy  and  control  process. 

(7)  Maintain  and  enhance  selected  ATLAS  compilers 
and  tools. 

lid.  The  JOVIAL  Language  Control  Agent  will  perform 
through  the  Language  Control  Facility  these  functions  as 
they  relate  to  JOVIAL  (J73) 


OFFICIAL  ALTON  D  SLAY,  General.  USAF 

Commander 


JAMES  L  WYATT.  JR..  Lt  Col.  USAF 
Director  of  Administration 
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CHAPTER  1 
GENERAL 

1-1.  Purpose.  This  regulation  implements  DOD  Directive  5000.29  Manage¬ 
ment  of  Computer  Resources  In  Major  Defense  Systems.  It  establishes 
policy  and  assigns  responsibilities  for  the  planning,  development, 
acquisition,  testing,  training,  and  support  of  major  and  non-major  Army 
battlefield  automated  systems  employing  computer  resources. 

1-2.  Scope.  a.  This  regulation  applies  to  Headquarters,  US  Army 
Materiel  Development  and  Readiness  Command  (DARCOM);  DARCOM  major 
subordinate  commands  (including  subordinate  installations  and 
activities);  DARCOM  program/pro ject/product  managers;  and  separate 
installations  and  activities  reporting  directly  to  HQ,  DARCOM. 

b.  The  systems  subject  to  the  provisions  of  this  regulation  are 
those  that  employ  computer  resources  and  operate  or  have  components  that 
operate  within  the  boundaries  of  the  battlefield  (Army  battlefield 
automated  systems). 

1-3.  Explanation  of  terms.  See  appendix  A. 

1-4 .  Objective.  The  objective  of  this  regulation  is  to  insure  that 
computer  resources  in  Army  battlefield  automated  systems  ^re  planned, 
developed,  tested,  acquired,  fielded,  and  supported  in  a  co6t  effective 
and  timely  manner. 

1-5.  Policy.  a.  Computer  resources  in  Army  battlefield  automated 
systems  will  be  managed  as  elements  of  major  importance  throughout  the 
entire  system  life  cycle  with  particular  emphasis  on  computer  software. 

b.  Validation  of  computer  resource  requirements  will  be  conducted 
during  the  Exploration  of  Alternative  Systems  Concepts  and  Demonstration 
and  Validation  Phases.  In  addition,  computer  resource  requirements  will 
be  continuously  coordinated  and  reconciled  with  system  operational 
requirements  throughout  system  acquisition. 

c.  Analyses  will  be  performed  prior  to  Milestone  II  to.  identify  risk 
areas  involving  planned  computer  resources.  The  risk  areas,  and  a  plan 
for  their  resolution  consistent  with  stated  operational  requirements, 
will  be  included  in  the  Materiel  Acquisition  Decision  Process  documenta¬ 
tion  at  the  Milestone  II  review. 
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d.  systems  wil  '  be  cu mpat  i  bit*  and  interoperable  with  other  s  vs  terns 
eraploved  by  all  .,;ul  Allied  mi  litary  fumes  where  the  svstem  under 
development  is  to  till  a  need  tor  such  compatibility  and  into r-->pe rnbi  litv 
I  nteroperabi  1  i  t  v  and  con;  .unicat  ions  support  requirements  tor  us  in;',  com¬ 
puter  resources  w; • 1  be  identified,  defined,  validated,  and  incluaed  in 
appropriate  planning  documentation  during  the  Demonstration  and 
Validation  Phase. 

e.  Systems  using  computer  resources,  where  applicable  and  cost 
effective,  will  include  provisions  for  training  simulations  or  programs. 

f.  Computer  resources  will  be  addressed  as  major  elements  during  all 
system  re  views. 

y.  Computer  resource  planning  shall  be  initiated  as  early  in  the 
system  life  cycle  as  possible.  Computer  resource  management  will  be 
included  in  the  Outline  Acquisition  Plan.  A  Computer  Resource  Management 
’’Ian  (CRMP)  will  be  orepared  lor  each  Army  battlefield  automated  system 
during  the  bemonstrat ion  and  Validation  Phase  of  system  acquisition.  The 
CRMP  will  identify  ir.ipor.ant  computer  resource  acquisition  and  life  cycle 
planning  factors  and  establish  specific  guidelines  to  insure  that  these 
factors  are  adequately  considered  in  the  acquisition  planning  process. 

The  CRMP  will  be  used  'o  support  the  other  formal  planning  documents 
required  throughout  fhe  system  life  cycle,  e.g. ,  Integrated  Logistic 
Support  Plan  and  Coordinated  Test  Program.  The  CRMP  is  the  primary 
document  used  to  establish  the  necessary  framework  and  support  system  for 
computer  software  control  during  production  and  post  deployment.  The 
CRMP  will  be  tailored  lor  each  Army  battlefield  automated  system.  It 
will  be  implemented  and  maintained  current  throughout  the  system  life 
cycle.  The  CRMP  will  be  prepared  by  the  materiel  developer,  in  coordina¬ 
tion  with  the  combat  developer,  development  and  operational  testers, 
development  and  operational  evaluators,  and  designated  readiness  activity 
System  acquisition  will  not  proceed  into  full  scale  engineering  develop¬ 
ment  until  the  CRMP  has  been  prepared  and  approved. 

h.  The  milestones  of  the  materiel  acquisition  decision  process  will 
be  used  to  manage  the  life  cycle  development  ot  computer  resources, 
including  software,  to  insure  the  proper  sequence  of  analysis,  design, 
documentation,  implementation,  integration,  test,  training,  operation, 
maintenance,  and  modification.  The  standard  decision  milestones  (o,  1, 
II,  III)  will  apply  in  accordance  with  guidance  contained  in  AR  1000-1. 

i.  Software  quality  and  support  will  be  addressed  as  a  major 
consideration  during  all  phases  of  the  system  life  cycle. 
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j.  Quality  Assurance  and  Configuration  Management  procedures  will  be 
developed,  specified  in  the  CRMP,  and  implemented  to  assure  proper  assess 
ment  and  control  of  computer  resources  and  their  requirements  throughout 
the  system  life  cycle.  Army  battlefield  automated  system  computer  re¬ 
sources,  including  both  computer  hardware  and  computer  software,  will  be 
specified  and  treated  as  configuration  items.  The  Configuration  Control 
Board  (CCB)  will  be  the  primary  medium  for  managing  hardware  and  software 
change  control  and  release  throughout  the  remaining  system  life  cycle. 
Membership  of  the  CCB  will  be  determined  by  the  materiel  developer  in 
accordance  with  the  provisions  of  AR  70-37  and  DARCOM  Supplement  1 
thereto. 


k.  A  Computer  Resources  Working  Group  (CRWG)  will  be  established  by 
the  materiel  developer  immediately  after  Milestone  1  for  each  system  to 
aid  in  the  management  of  the  system's  computer  resources.  The  prime 
purpose  of  the  CRWG  is  to  assist  the  materiel  developer  in  initiating 
early  tasks  and  activities  that  are  prerequisites  to  development  and  test 
functions  (such  as  configuration  management,  system  level  testing  and 
post  development  support. )  The  CRWG  will  assist  in  insuring  the 
compliance  with  policy,  procedures,  plans,  and  standards  established  for 
computer  resources.  Membership  will  include  the  combat  developer, 
materiel  developer,  development  and  operational  testers  and  evaluators, 
and  designated  post  deployment  support  activities. 

l.  Computer  resources,  including  hardware,  software,  and  support 
items,  with  associated  documentation  required  for  the  development  and 
support  of  operational  systems,  will  be  specified  as  deliverable  items  in 
all  solicitation  documents  with  the  Government  acquiring  rights  and  data 
as  specified  in  the  Defense  Acquisition  Regulation  (DAR). 

m.  Computer  resources  will  be  standardized  to  the  extent  practicable 
within  each  system  as  well  as  across  systems. 

n.  Already  developed  computer  resources  will  be  used  to  the  maximum 
extent  practicable  in  Army  battlefield  automated  systems. 


o.  Organic  computer  equipment  maintenance  and  computer  program  devel 
opment  and  maintenance  capabilities  will  be  established  where  economical 
or  to  satisfy  system  requirements.  Common  or  existing  capabilities  will 
be  used  wherever  practicable. 


p.  Army  battlefield  automated  systems  that  Include  commercial 
computer  rer  es  will  be  developed  and  managed  in  accordance  with  the 

provisions  's  70-1,  700-127,  1000-1  and  DARCOM  Supplement  1  to  AR 

700-127. 


107 


DARCOM-R  70-16 


q.  DOD  approved  High  Order  Programming  Languages  (HOL's)  (DOD 
Instruction  5000.  'll  ,  will  be  used  to  develop  all  Army  battlefield 
automated  system  software,  unless  it  can  be  demonstrated  that  none  of  the 
approved  HOL's  are  cost-effective  or  technically  practicable  over  the 
system  life  cycle.  The  Assistant  Chief  of  Staff  for  Automation  and 
Communications  (ACSAC),  is  the  designated  approving  authority  for 
exceptions  to  this  policy.  Request  for  approval  of  exceptions  will  be 
submitted  through  the  Commander,  DARCOM,  ATTN:  DRCDE-C. 

r.  Test  support  facilities  required  to  test  hardware,  firmware  and 
software  for  development,  production  and  deployment  will  be  included  in 
system  acquisition  plans  in  accordance  with  the  provisions  of  AR  70-1. 

s.  An  inventory  of  computer  equipment  and  computer  programs  included 
in  Arc.'  battlefield  automated  systems  will  be  maintained. 

t.  For  all  Army  Battlefield  Automated  Systems  employing  computer 
resources,  both  software  and  hardware  will  be  subject  to: 

(1)  Formal  materiel  release  certification  procedures  in  accordance 
with  DARCOM-R  700-34. 

(2)  Transitioning  of  management  responsibility  from  the  materiel 
developer  to  readiness  command  will  be  accomplished  in  accordance  with 
DARCOM-R  70-1. 

1-6.  Responsibilities.  The  responsibilities  and  major  functions  of 
Headquarters,  DARCOM  and  the  DARCOM  major  subordinate  commands  are 
established  in  DARCOM-R  10  series.  Specific  responsibilities  with 
respect  to  computer  resource  management  in  Army  battlefield  automated 
systems  follows: 

a.  Headquarters,  DARCOM.  The  Associate  Director  of  Battlefield 
Automation  Management  within  the  Directorate  for  Development  and 
Engineering.  DARCOM.  will  be  responsible  for: 

(1)  The  overall  DARCOM  computer  resource  management  policy  for  Army 
battlefield  automated  systems  to  insure  that  policies  and  procedures  for 
the  management  of  computer  resources  are  consistent  with  applicable 
policies,  regulations,  and  directives. 
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(2)  In  conjunction  with  the  Office  of  Laboratory  and  Development 
Management,  develop,  coordinate,  and  submit  to  Department  of  the  Army 
(DA),  the  DARCOM  Research  and  Development  Technology  Base  Program  for 
Computer  Resources,  to  insure  the  availablity  of  advanced  and  innovative 
computer  hardware  and  software  technology  necessary  to  support  Army 
battlefield  automated  system  needs. 

(3)  Reviewing  and  approving  the  CRMP  for  each  Army  battlefield 
automated  system  to  insure  proper  planning  and  logistic  supportability  of 
the  system  throughout  the  life  cycle. 

(4)  Coordinating  the  DARCOM  computer  resources  and  system  engineer¬ 
ing  activities  and  programs  for  battlefield  automated  systems  with  TRADOC, 
and  other  Army /service  commands  as  appropriate. 

b.  Subordinate  Commands.  The  commanders  of  research  and  development 


commands,  materiel  readiness  commands,  and  program/prolect/product 


managers,  and  separate  installations  and  activities  will  (unless  otherwise 


specified  by  an  individual  organizational  responsibility): 

(1)  Prepare  the  CRMP  to  provide  effective  life  cycle  support  for  Army 
battlefield  automated  systems  using  computer  resources. 

(2)  Provide  the  necessary  support  for  fielded  systems. 

(3)  Provide  the  development,  test  and  evaluation  of  the  necessary 
logistic  support  and  Insure  that  systems  are  supportable  prior  to 
fielding. 

(4)  Provide  automated  system  accreditation  authority  in  accordance 
with  the  provisions  of  AR  380-380. 

(3)  Implement  the  policies  contained  herein. 

c.  US  Army  Communications  Research  and  Development  Command 


(CORADCCM)  Ft.  Monmouth,  NJ.  The  Commander,  CORADCOM,  will  be 


(1)  Standardizing  computer  equipment,  c 
software  among  and  within  Army  battlefield  a 
optimum  usage  of  available  computer  resource 
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(2)  Achieving  and  ra«? r  ntaining  technical  compatibility  and 
interoperability  among  Army  battlefield  automated  systems  and  those  of 
the  other  services  or  allies  for  which  such  requirements  have  been 
identified. 


(3)  Maintaining  an  organic  capability  for  the  development,  coordina¬ 
tion,  and  DARCOM-wide  implementation  of  computer  resource  management  pro¬ 
cedures,  guidelines,  and  standards  applicable  to  Army  battlefield  automated 
systems. 

(4)  Developing  and  maintaining  the  Army  inventory  of  all  computer 
equipment  and  computer  programs  included  in  Army  battlefield  automated 
systems. 

(5)  Providing  the  focal  point  for  Defense  system  HOL  efforts  and  the 
language  control  facility  assigned  to  DASjCOM  for  those  DOD-approved 
languages  under  the  Army  purview  in  accordance  with  DODI  5000.31. 

d.  US  Army  Test  and  Evaluation  Command  (TECCM.),  Aberdeen  Proving 
Ground,  MD.  The  Commander,  TECOM,  will  be  responsible  for  developing  the 


capability  and  methods  necessary  to: 

(1)  Support  test  and  evaluation  of  Army  battlefield  automated  systems 
during  development  and  production  (development  test  and  First  Article 
Test  (FAT)).  The  extent  of  TECOM  involvement  in  FAT  will  be  as  mutually 
agreed  between  TECOM  and  the  test  proponent. 

(2)  Determine  system  conformance  with  established  requirements 
(performance,  environmental,  safety,  human  engineering,  cost  constraints, 
reliability,  availability,  maintainability,  etc-). 

(3)  Conduct  testing  in  a  realistic  environment  whenever  practical. 
However,  when  simulation  or  static  testing  is  performed,  emphasis  should 
be  placed  on  providing  a  controlled  and  reproducible  test  environment 
that  stress  the  system  design  limits  (worst-case  testing). 

(4)  Participate  in  materiel  release  certification  in  accordance  with 
DARCOM-R  700-34. 
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CHAPTER  2 

LIFE  CYCLE  COMPUTER  RESOURCE  MANAGEMENT 

2-1.  General.  The  acquisition  and  support  of  computer  resources  in  Army 
battlefield  automated  systems  will  be  planned  and  managed  as  elements  of 
major  importance  throughout  the  system  acquisition  process.  Computer 
resource  management  requirements  will  be  included  in  the  life  cycle  sys¬ 
tem  acquisition  process  and  the  associated  documentation.  The  intent  of 
this  chapter  is  to  insure  that  computer  resources  in  Army  battlefield 
automated  systems  are  treated  and  managed  as  integral  but  subordinate 
parts  of  the  overall  system  and  not  as  separate  or  unique  elements.  To 
the  extent  feasible,  computer  resource  management  requirements  promul¬ 
gated  in  this  regulation  will  be  included  in  the  acquisition  process. 

2-2.  System  life  cycle,  a.  Systems  containing  computer  resources  shall 
satisfy  all  milestone  and  phase  requirements  of  the  System  Life  Cycle  as 
defined  in  AR's  70-1,  700-127,  1000-1,  and  DARCOM  Supplement  1  to  AR  700- 
127.  These  regulations  emphasize  flexibility  and  require  an  acquisition 
strategy  tailored  to  each  individual  program.  In  addition,  special 
emphasis  and  interpretation  will  be  applied  at  the  major  technical  and 
systems  milestones  as  indicated  below. 

b.  Milestones  definition  and  attainment  criteria. 

(1)  Computer  resources  will  be  considered  during  each  phase  of  the 
acquisition  cycle  and  at  each  milestone.  Development  of  computer 
resources  necessitate  clear  specification  of  requirements,  appropriate 
allocation  of  functions  between  hardware  and  software,  and  a  division  of 
large  systems  into  manageable  subsystems.  The  software  milestones  and 
attainment  criteria  enq>hasize  those  actions  that  must  be  satisfactorily 
completed  prior  to  progressing  from  one  system  acquisition  phase  to  the 
next. 

(2)  In  all  Array  battlefield  automated  systems  the  hardware  and  accom 
panying  software  will  proceed  through  the  system  life  cycle  concurrently. 
A  system  will  not  be  approved  for  advancement  to  the  next  acquisition 
phase  until  both  hardware  and  software  have  satisfied  all  requirements  of 
the  earlier  phase.  The  following  milestone  attainment  criteria  is  a 
summary  of  the  additional  requirements  established  herein  for  those  sys¬ 
tems  containing  computer  resources: 

(a)  Milestone  0  -  Decision  for  Program  Initiation.  The  planning 
process  begins  with  the  identification  of  personnel  having  the  requisite 
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computer  experience  and  skills  required  to  conduct  the  investigation 
throughout  the  Exploration  of  Alternate  System  Concepts  Phase. 

(b)  Milestone  1  -  Decision  to  enter  Demonstration  and  Validation 
Phase. 

_1.  The  Materiel  Acquisition  Decision  Process  (MADP)  documentation 
(Outline  Acquisition  Plan  (0AP)/Army  Program  Memorandum  (APM)/Decision 
Coordination  Paper  (DCP)  etc.,)  will  identify  the  potential  computer 
resource  implications  and  associated  risk  areas  of  the  proposed  system 
acquisition. 

2.  The  System  Specification  (Type  A,  MIL-STD  490)  must  be  prepared 
and  the  System  Requirements  Review  completed  prior  to  Milestone  I. 

3.  Prepare  a  draft  CRMP. 

4.  Computer  resource  considerations  for  milestone  review  are  listed 
in  appendix  C, 

(c)  Milestone  II  -  Decision  to  enter  Full-Scale  Engineering  Develop¬ 
ment  Phase. 

JL.  Establish  the  CRWG. 

2.  The  CRMP  is  updated,  approved,  and  included  as  part  of  the  MADP 
documentation. 

J3.  The  Development  Specification  (Type  B-5,  MIL-STD  490)  is  prepared 
and  System  Design  Review  completed. 

4.  Computer  resource  considerations  for  milestone  review  are  listed 
in  appendix  C. 

(d)  Milestone  III  -  Decision  to  enter  Production  and  Deployment 
Phase. 

1.  Update  CRMP. 

2.  Prepare  Product  Specification  (Type  C-5,  MIL-STD-490)  and  perform 
Preliminary  and  Critical  Design  Reviews. 

_3.  Computer  resource  considerations  for  milestone  review  are  listed 
in  appendix  C, 
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(3)  Technical  Milestones  and  Attainment  Criteria. 

(a)  System  specification.  A  System  Specification  (Type  A,  MIL  STD 
490)  will  be  prepared  during  the  Program  Exploration  of  Alternative 
System  Concepts  Phase  by  the  materiel  developer  in  coordination  with  the 
combat  developer  to  establish  the  system  baseline  functional  requirements. 
A  technical  review  and  evaluation  (System  Requirements  Review)  of  this 
specification  will  occur  prior  to  Milestone  1.  In  cases  where  ASARC/ 

DSARC  1  review  is  not  required,  the  designated  approval  authority 

(AR  70-1)  will  coordinate  the  necessary  technical  review  and  approve 
entry  into  the  Demonstration  and  Validation  Phase.  The  System 
Specification  will  be  placed  under  Government  configuration  management 
upon  entry  into  the  Demonstration  and  Validation  phase  and  will  be 
maintained  under  Configuration  Management  throughout  the  system 
acquisition. 

(b)  Development  specification.  A  Development  Specification  (Type  B, 
MIL-STD-490)  will  be  prepared  by  the  materiel  developer  prior  to  Mile¬ 
stone  II  or  equivalent  reviews.  For  systems  with  integral  computer  com¬ 
ponents,  particular  attention  will  be  paid  to  the  allocation  of  functions 
between  computer  and  noncomputer  resources.  Functions  allocated  to  soft¬ 
ware  will  be  documented  in  the  Computer  Program  Development  Specification 
(Type  B-5,  MIL-STD-490).  The  Development  Specification  will  establish 
the  design  necessary  to  implement,  test,  and  maintain  the  functional 
requirements  established  in  the  System  Specification.  The  Development 
Specification  will  be  placed  under  Government  configuration  management 
upon  entry  into  the  Full-Scale  Engineering  Development  phase  and  will  be 
maintained  under  Government  configuration  management  throughout  the 
system  life  cycle. 

(c)  Product  specification.  A  Product  Specification  (Type  C,  MIL-STD- 
490)  will  be  prepared  by  the  materiel  developer  prior  to  Milestone  III 
review  or  prior  to  a  development  acceptance  review  for  non-major  systems. 
The  Product  Specification  documents  the  details  of  system  implementation 
for  production  and  maintenance.  The  Computer  Program  Product  Specifica¬ 
tion  (Type  C-5  MIL-STD-490)  details  the  system  software  implementation, 
which  in  fact  documents  the  system  production  software.  The  Product 
Specification  will  be  placed  under  Government  configuration  management 
upon  delivery  and  will  be  maintained  under  Government  configuration 
management  throughout  the  balance  of  the  system  life  cycle. 

(d)  System  requirements  review  (SRR).  The  objective  of  this  review 
is  to  ascertain  the  adequacy  of  the  contractor's  efforts  in  defining 
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system  requirements.  Independent  validation  of  the  system  Specification 
(Type  A,  MIL-STD-490)  shall  be  performed  prior  to  approval.  It  will  be 
conducted  when  a  significant  portion  of  the  system  functional  require¬ 
ments  has  been  established.  (AR  70-37  and  DARCOM  Supplement  I  thereto 
and  MIL-STD-1 521 ). 

(e)  System  design  review  (SDR).  This  review  shall  be  conducted  when 
the  definition  effort  has  proceeded  to  the  point  (Type  B-5  Computer  Pro¬ 
gram  Development  Specification,  MIL-STD-490)  where  system  requirements 
and  the  design  approach  are  more  precisely  defined,  (i.e. ,  alternate 
design  approaches  and  corresponding  test  requirements  have  been  consi¬ 
dered  and  the  contractor  has  defined  and  selected  the  required  equipment, 
logistic  support,  personnel,  procedural  data,  and  facilities).  This 
review  shall  be  in  sufficient  detail  to  insure  a  technical  understanding 
between  the  contractor  and  the  procuring  activity  on:  The  system  seg¬ 
ments  identified  in  the  system  specification  and  the  configuration  items 
identified  in  the  Computer  Program  Configuration  Item  (CPCI)  Development 
Specif ication(s)  (AR  70-37  and  DARCOM  Supplement  1  thereto  and  MIL-STD- 
1521). 

(f)  Preliminary  design  review  (PDR).  A  PDR  will  be  conducted  for 
each  CPCI,  or  for  a  group  of  functionally  related  CPCI's.  Its  purposes 
will  be:(l)  evaluate  the  progress  and  technical  adequacy  of  the  selected 
design  approach;  (2)  determine  the  CPC  Is  compatibility  with  the  perfor¬ 
mance  requirements  of  its  development  specification;  and  (3)  establish 
the  compatibility  of  the  Interfaces  between  the  CPCI  and  other  items  of 
equipment  for  facilities.  The  PDR  will  be  a  formal  technical  review  of 
the  basic  design  approach.  It  will  be  conducted  after  approval  of  the 
development  specification  and  after  the  accomplishment  of  preliminary 
functional  design  efforts,  but  prior  to  the  start  of  detailed  design.  The 
PDR  assures  the  CPCI  functional  flowcharts,  memory  allocation  charts, 
control  functions,  and  data  base  are  adequate  (AR  70-37  and  DARCOM 
Supplement  1  thereto  and  MIL-STD-1521). 

(g)  Critical  design  review  (CDR).  The  CDR  will  be  a  formal  techni¬ 
cal  review  of  the  detailed  CPCI  allocated  Computer  Program  Component 
(CPC).  This  review  established  the  integrity  of  the  program  design,  at 
the  level  of  detailed  flowcharts  or  logical  design,  prior  to  coding  and 
testing.  It  will  be  conducted  for  a  single  CPC,  or  for  functionally 
related  CPC's,  when  detailed  design  is  essentially  complete,  and  when  the 
draft  computer  program  product  specification  and  test  procedures  (Type 
C-5,  MIL-STD-490)  have  been  prepared.  The  purposes  of  the  CDR  will  be: 

(1)  determine  the  detailed  design  of  the  CPC  satisfies  the  performance  and 
design  requirements  established  in  its  development  specification; 
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(2)  establish  the  exact  interface  relationships  between  the  CPC  and  other 
programs  or  items  of  equipment  and  facilities;  an<j  (3)  review  interactions 
with  the  data  base.  The  draft  product  specification  will  be  revised  to 
reflect  the  recommendations  of  the  CDR  (AR  70-37  and  DARCOM  Supplement  1 
thereto  and  MIL-STD-1521 ). 

(h)  Formal  qualification  review  (FQR).  A  FQR  will  be  held  for  each 
CPCI  in  order  to  establish  that  the  end  item  software  meets  the  contractual 
and  performance  requirements.  The  objective  of  the  FQR  will  be  to  verify 
that  the  actual  performance  of  the  CPCI  complies  with  its  development 
specification,  and  to  identify  test  reports  and  data  that  document  the 
results  of  the  program  qualification  tests.  Input  to  the  FQR  consists  of 
the  final  test  results  of  each  CPCI  in  an  operational  environment.  The 
FQR  will  be  conducted  with  the  FCA,  after  the  formal  qualification  tests, 
when  sufficient  test  results  are  available  to  insure  that  the  CPCI  will 
perform  in  its  system  environment  (AR  70-37  and  DARCOM  Supplement  1 
thereto  and  MIL-STD-1521). 

(i)  Functional  configuration  audit  (FCA).  A  FCA  will  be  performed 
for  each  CPCI.  This  audit  will  be  a  formal  examination  of  the  CPCI 
functional  characteristics  and  test  data,  which  verifies  that  the  CPCI 
has  achieved  the  performance  specified  in  the  development  specification. 

The  FCA  will  be  conducted  with  the  FQR,  after  the  formal  qualification 
test  has  been  completed.  At  the  FCA,  the  test  plans,  procedures,  and 
test  results  will  be  reviewed  for  compliance  with  specification  require¬ 
ments.  The  FCA  determines  whether  all  of  the  requirements  have  been  met, 
and  whether  any  tests  should  be  repeated  (AR  70-37  and  DARCOM  Supplement 
1  thereto  and  MIL-STD-1521). 

(j)  Physical  configuration  audit  (PCA).  A  PCA  will  be  conducted  for 
each  CPCI  to  establish  that  the  CPCI  technical  data  package  is  complete, 
and  that  all  physical  items  called  for  by  the  contract  have  been  produced 
in  the  specified  conflguraton.  The  PCA  will  be  conducted  on  a  CPCI  that 
is  representative  of  the  configuration  specified  as  the  production 
contract  deliverable.  A  detailed  audit  of  the  product  specif lcation(s ) 
and  the  physical  items  included  in  the  technical  data  package  will  be 
performed.  Approval  of  the  Product  Specif ication(s )  establishes  the 
product  baseline  (AR  70-37  and  DARCOM  Supplement  1  thereto  and 
MIL-STD-1521). 

2-3.  Computer  resource  management  plan  (CRMP).  A  CRMP  will  be  developed 
by  the  materiel  developer  in  coordination  with  the  combat  developer, 
development  and  operational  testers  and  evaluators  and  designated  post 
deployment  support  activities  prior  to  Milestone  II  and  will  be 
maintained  throughout  the  system  life  cycle.  The  CRMP  will  be  keyed  to 
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overall  system  act,;  sitlor  milestones  and  schedules.  The  CRMP  is  the 
primary  document  to  be  used  at  all  decision  levels  for  assessment  as  to 
the  adequacy  of  overall  computer  resource  management  efforts.  The  CRMP 
will  be  developed  as  an  annex  to  the  System  Acquisition  Plan  and  will  be 
approved  by  the  Commander,  DARCOM ,  ATTN:  DRCDE-C,  prior  to  implementation. 

a.  The  purpose  of  the  CRMP  is  to  identify  computer  resources 
acquisition  and  life  cycle  planning  factors  and  to  insure  that  these 
factors  are  adequately  considered" in  the  acquisition  planning  process. 

The  CRMP  (see  app  B  for  format)  will  address,  as  a  minimum,  the 
following : 

(1)  Responsibilities  for  integration  of  computer  resources  into  the 
total  stem  and  the  test  and  evaluation  of  that  system  to  determine 
enti  system  quality  and  integrity. 

(2)  Computer  programs  required  to  support  the  development,  production, 
deployment  and  post  deployment  support  of  the  total  system. 

(3)  Personnel  requirements  for  developing  and  supporting  computer 
resources. 

(4)  Provisions  for  the  transfer  of  system  management/operational/ 
support  responsibility  from  the  materiel  developer  to  the  user/support 
organizations. 

(5)  Complete  management  planning  for  the  acquisition,  test,  evalua¬ 
tion  and  post  deployment  support  for  all  functions  related  to  the  computer 
resources  in,  or  in  support  of,  the  Army  battlefield  automated  system. 

(6)  The  method  by  which  the  post  development  software  support 
concepts/procedures  are  tested  (supportability  demonstration  planning). 

b.  The  CRMP  will  be  tailored  to  the  specific  aspects  and  require¬ 
ments  of  the  Army  system. 

c.  The  CRMP  is  not  intended  to  replace  other  required  plans  that 
support  overall  system  requirements,  e. g. ,  Coordinated  Test  Program, 
Integrated  Logistic  Support  Plan,  Quality  Assurance  Plan. 

2-4.  Computer  resource  management.  Requirements  for  computer  resources 
evolve  from  overall  system  requirements  as  a  result  of  applying  system 
engineering  disciplines.  The  system  configuration  which  results  must 
meet  the  total  system  functional  requirements  in  the  most  cost-effective 
manner.  This  is  accomplished  by  insuring  every  system  element,  including 
computer  resources,  is  included  in  the  total  system  optimization.  Com¬ 
puter  resources  as  such  are  considered  to  be  an  integral  part  of  the 
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system  and  are  subject  to  trade-off  and  optimization  in  the  same  manner 
as  other  system  elements.  Therefore,  the  management  of  computer  re¬ 
sources  is  accomplished  in  the  larger  context  of  the  overall  system  pro¬ 
gram  technical  and  management  efforts.  The  areas  covered  below  will  be 
considered  in  the  development  of  the  overall  system  plans  and  will  be 
specifically  addressed  in  the  CRMP.  Type  classification  of  Army  battle¬ 
field  automated  systems  containing  computer  resources  will  be  done  in 
accordance  with  the  provisions  of  AR  70-61. 

a.  System  engineering  management. 

(1)  The  materiel  developer  will  be  responsible  for  managing  the 
total  engineering  effort  during  the  system  life  cycle.  The  materiel 
developer  will  assure  that  system  engineering  applied  to  computer  re¬ 
sources  is  adequately  planned,  executed  and  evaluated,  and  will  result  in 

computer  resources  that  meet  operational  and  support  needs.  ' 

(2)  Computer  resource  requirements  validation  and  risk  assessment 
will  be  managed  as  key  elements  of  the  system  engineering  management 
effort,  Integral  to  overall  system  acquisition. 

(3)  The  principal  products  produced  by  the  materiel  developer  during 
the  system  engineering  effort  are  the  System  Specification,  Development 
Specification,  Product  Specification  for  the  system's  configuration  items 
(MIL  STD  490),  and  technical  documentation,  such  as  trade-off  study 
reports,  test  documentation,  and  user/operator  documentation. 

b.  Requirements  validation.  The  objective  of  computer  resource 
requirements  validation  is  to  assure  requirements  and  specifications  are 
consistent,  sufficient,  and  unambiguous.  During  the  Demonstration  and 
Validation  Phase  the  materiel  developer  will  address  computer  resource 
requirement  validation  as  an  integral  part  of  the  overall  system  require¬ 
ments  validation.  Computer  resource  requirements  must  be  validated  prior 
to  the  approval  of  development  specifications.  The  validation  process 

will  Include  the  approach  to  be  used  in  insuring  the  systems  specifics-  j 

tions  meet  the  user  requirements.  This  validation  process  will  insure 
that: 

(1)  System  operational  concepts  and  approved  mission  profiles  are 
available. 

(2)  The  system  functions  allocated  to  computer  resources  are  clearly 
Identified  and  attainable,  and  traceable  to  the  system  requirements 
specification. 
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c.  Risk  analysis  and  management.  Risk  analysis  and  management,  which 
includes  elements  of  risk  identification,  planning,  analysis,  evaluation, 
resolution,  and  review,  will  be  completed  for  computer  resources  prior  to 
Milestone  II.  Computer  resource  risk  analysis  and  management  will  be 
closely  coordinated  with  the  requirements  validation  effort  and  the  over¬ 
all  systems  engineering  effort  to  assure  that  the  risks  associated  with 
achieving  validated  cost,  schedule,  and  technical  performance  requirements 
are  identified  and  assessed  in  advance,  are  within  acceptable  thresholds, 
and  are  continuously  monitored  and  reported  during  subsequent  development. 

d.  Contracting.  The  contracting  strategy,  planning,  and  techniques 
for  acquiring  computer  resources  will  be  stated  in  the  CRMP.  All  pro¬ 
posed  Army  contracts  for  system/major  item  acquisition,  modification, 

or  support  will  conform  to  the  provisions  of  paragraph  1-5.1  and  will 
specify  specific  data  items  to  be  delivered.  Full-scale  engineering 
development  contracts  for  systems  including  computer  resources  will  not 
be  awarded  prior  to  approval  of  CRMP. 

e.  Configuration  management  (CM). 

(1)  CM  is  a  discipline  applying  technical  and  administrative  direc¬ 
tion  and  surveillance  throughout  the  systems  life  cycle. 

(2)  CM  is  intended  to: 

(a)  Assist  the  materiel  developer  in  achieving,  at  lowest  possible 
life  cycle  cost,  the  required  performance  within  realistic  schedules 
while  insuring  the  operational  efficiency  of  the  configuration  item  (Cl). 

(b)  Allow  the  maximum  degree  and  development  latitude  yet  introduce 
at  the  appropriate  time  the  degree  and  depth  of  management  and  earliest 
technical  control  of  configuration  items  necessary  for  effective  develop¬ 
ment  and  follow-on  production  and  logistic  support. 

(c)  Attain  maximum  efficiency  in  the  management  of  configuration 
changes  with  respect  to  their  necessity,  cost,  timing,  and  implementation. 
The  materiel  developer  will  design  and  tailor  the  configuration  manage¬ 
ment  program  in  accordance  with  AR  70-37.  Specifically,  computer  soft¬ 
ware,  as  well  as  computer  hardware,  will  be  specified  and  treated  as 
separate  configuration  items.  The  configuration  management  procedures 
specified  in  AR  70-37  and  DARCOM  Supplement  1  thereto  will  provide  for 
categorizing  all  software  modifications,  implementing  changes,  assessing 
changes,  determining  level  of  test ing/ validation  effort,  and 
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controlling  release  of  new  software  system  versions  to  the  distribution 
points.  The  CCB  will  be  responsible  for  establishing  and  maintaining  a 
record  of  all  computer  software  configuration  change  actions.  The  record 
must  be  in  sufficient  detail  to  provide  an  audit  trail,  document  the 
technical  evaluations  and  CCB  decisions,  and  provide  a  current  configura¬ 
tion  status  of  the  CPCI. 

(3)  For  the  purpose  of  controlling  and  validating  software  changes/ 
modifications,  the  CCB  will  be  responsible  for  determining  the  validity 
of  all  proposed  changes/modifications  to  an  Army  Battlefield  Automated 
System,  approving/disapproving,  and  classifying  the  approved  proposals 
into  the  following  categories:  (A  clear  distinction  will  not  always  be 
available;  however,  classification  responsibiilty  rests  with  the  CCB. 

The  CCB  decision  rationale  will  be  entered  into  the  change  action  record. ) 

(a)  System  refinement  software  changes  usually  deal  with  program 
optimization,  error  correcting,  improving  system  performance,  and 
incorporating  technological  advances.  Changes  of  this  nature  usually  do 
not  deal  with  major  changes  in  application.  Included  in  this  category, 
however,  are  evolutionary  modifications  to  major  weapon  system  tactical 
software  in  response  to  evolving/changing  tactical  doctrine  and  threat. 

(b)  New  requirement  are  program  modifications  which  result  from 
major  changes  or  new  applications. 

(c)  Interoperability  interface  configuration  changes/modif icat ions 
are  those  affecting  the  design  baseline  of  those  systems  controlled  by 
Battlefield  Interface  Implementation  Plans,  Interoperability  Design 
Standards,  or  Army  Technical  Interface  Design  Plans. 

(4)  Those  proposed  changes/modifications  classified  as  interopera¬ 
bility  interfaces  must  be  forwarded  to  the  Army  Interoperability  Con¬ 
figuration  Control  Working  Group/Steering  Couittee  for  approval  to 
Implement.  The  implementation  of  approved  interoperability  interface 
changes/modifications  will  be  In  accordance  with  the  instructions 
provided  by  the  approving  authority.  The  implementation  of  changes/ 
modifications  not  classified  as  an  interoperability  interface  will  be 
handled  as  follows: 

(a)  Changes  categorized  as  new  requirements  are  to  be  managed  as  a 
Product  Improvement  Proposal  (PIP)  in  accordance  with  AR  70-15.  The  cost 
of  product  improvements  will  be  carefuly  weighed  against  the  expected 
improvements  in  reliability,  maintainability,  operational  readiness,  and 
operational  capabilities  and  effectiveness  within  the  remaining  life 
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(b)  Software  in  the  system  refinement  category  will  be 

recycled  back  into  the  Full-Scale  Engineering  Development  Phase  and  all 
software  documentation  will  be  reviewed  and  updated  accordingly.  All 
systems  refinements  changes  will  not  necessarily  require  the  same  magni¬ 
tude  of  effort  fcr  incorporating  and  validating  the  change.  The  nature 
of  the  change/mocif ication  will  dictate  the  level  of  effort  necessary  to 
implement  and  the  magnitude/type  of  test  program  necessary  to  validate 
the  changes.  After  completion  of  the  verification  testing,  the 
configuration  change (s)  will  be  documented  by  an  Engineering  Change  Pro¬ 
posal  (ECP)  with  the  necessary  accompanying  documents,  e.g. ,  Notice  of 
Revision  (NOR),  test  reports,  technical  evaluations  (MIL-STD's  480,  481, 
482, and  483).  The  new  software  version  that  results  from  a  change  or 
group  of  changes  may  reenter  the  Production  and  Deployment  Phase  after 
the  comb-t  developer  concurs  in  the  adequacy  of  the  testing  and  the  CCB 
approv-  .>  the  ECP.  Prior  to  the  issue  of  a  new  software  version  to  the 
fiel'",  the  materiel  developer  must  complete  a  formal  release  certifica¬ 
tion  in  accordance  with  DARCOM-R  700-34.  The  ECP,  CCB  decisions,  combat 
caveloper's  concurrence,  and  release  certification  will  be  made  part  of 
the  change  action  record. 

f.  Test  management  (TM). 

(1)  Computer  resource  testing  will  be  accomplished  throughout  the 
life  cycle  of  a  system  to  provide  data  relative  to  the  state  of  the 
system  development  or  operation  of  the  computer  resources  segment  of  the 
system.  Proper  TM  will  assure  that  timely  and  adequate  testing  is 
performed  to  verify  required  technical  and  operational  capabilities  of 
the  computer  resources  as  well  as  the  overall  system  and  system  inter¬ 
faces. 

(2)  Materiel  developers  will  prepare  TM  plans,  as  early  as  possible, 
and  will  summarize  overall  TM  efforts  in  the  Computer  Resource  Management 
Plan.  The  Coordinated  Test  Program  (CTP)  will  continue  to  be  the  basic 
document  to  address  test  and  evaluation  of  the  Army  battlefield  systems, 
including  those  which  contain  computer  resources.  Computer  resources 
will  be  specifically  addressed  in  all: 

(a)  Development  Tests  (DT's),  Operational  Tests  (OT's),  Test  Design 
Plans  (TDP's),  and  Outline  Test  Plans  (OTP's). 

(b)  Independent  Evaluation  Plans  (IEP's). 

(c)  Government  performed  Engineering  Design  Test  Plans  pertaining  to 
computer  resources. 
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(d)  Contractor  test  plans  pertaining  to  computer  resources. 

(3)  Test  planning  for  computer  resources  will  insure  that  testing  is 
adequate  and  not  redundant  throughout  the  life  cycle;  that  support 
equipment/sof tware  instrumentation  including  such  items  as  test  drivers, 
data  records,  and  monitors  are  validated,  placed  under  configuration 
control,  and  acquired  in  a  timely  manner. 

(A)  Test  planning  will  also  provide  for  an  independent  assessment 
and  evaluation  of  the  contractor's  computer  resources  performance  demon¬ 
stration  testing  by  the  materiel  developer  prior  to  acceptance  for 
Government  testing. 

(5)  Computer  resource  test  planning  and  management  as  contained  in 
the  CRMP  and  CTP  will  be  reviewed  by  the  Computer  Resource  Working  Group 
prior  to  Milestone  II. 

(6)  Test  support  facility  requirements  will  be  considered  as  an 
integral  part  of  the  overall  system  acquisition  and  will  be  designed  to 
be  used  throughout  the  system  life  cycle.  As  a  minimum,  test  support 
facilities  will  include  the  necessary  computer  hardware,  software, 
environmental  simulators,  hardware  and  software  monitors,  test  case  gen¬ 
erators  and  analyzers,  training  aids,  and  collection  and  data  reduction 
equipment  required  to  demonstrate  and  validate  system  performance  and 
provide  for  system  maintenance.  Test  support  facility  requirements  to  be 
provided  by  the  developing  contractor  will  be  included  as  deliverable 
items  on  the  contract  and  will  be  consistent  with  those  test  support 
requirements  necessary  for  Government  development  and  operational  test 
and  system  post  deployment  support.  If  practicable,  Government -owned 
test  support  facilities  and  equipment  will  be  made  available  for 
contractor  use  during  the  Demonstration  and  Validation  and  Full-Scale 
Engineering  Development  phases  of  the  system  acquisition  in  order  to 
prevent  duplication. 

(7)  Test  planning  during  the  production  and  post  deployment  phase 
will  be  designed  in  accordance  with  the  following  provisions: 

(a)  Acceptance  testing  is  mandatory  for  revalidation  of  all  new 
versions  of  computer  software  irrespective  of  the  impetus  for  the  change, 
i.e. ,  system  refinement,  new  requirement. 

(b)  Prior  to  the  Issuance  of  any  new  versions  of  computer  software 
to  the  field,  the  new  software  version  must  undergo  formal  release 
certification,  in  accordance  with  DARCOM-R  700-34. 
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g.  Quality  assurance. 

(1)  The  materiel  developer  will  develop  independent  assessment 
procedures  to  insure  that  the  product  will  meet  management  policies  and 
appropriate  regulations,  conform  to  standards,  and  meet  performance  and 
quality  requirements  throughout  the  life  cycle. 

(2)  Product  assurance  for  systems  using  computer  resources  will  be 
achieved  by  performing  continuous  assessments  throughout  the  system  life 
cycle,  in  accordance  with  the  guidance  delineated  in  DA  PAM  11-25.  The 
contractor's  Software  Quality  Assurance  Program  (MIL-STD  52779  (AD))  must 
be  approved  by  the  Government  prior  to  software  development.  Those 
assessments  include  reviews,  audits,  verification,  testing,  and  enforce¬ 
ment  activities  applied  to  procedural  and  to  product  aspects  of  the 
system  development.  Results  of  assessments  will  be  documented  and  will 
be  5-uDject  to  Materiel  Acquisition  and  Decision  Process  (MADP)  reviews  in 
accordance  with  the  guidance  contained  in  chapter  2,  AR  70-1. 

(3)  Computer  resources  product  assurance  planning  will  be  addressed 
in  the  CRMP.  The  Product  Assurance  Plan  called  for  in  AR  70-27  will 
continue  to  be  the  primary  document  for  overall  system  product  assurance 
planning.  As  a  minimum,  the  CRMP  will  Include: 

(a)  System  project  organization  and  interface  among  the  system  devel 
opment  community  including  responsibilities  of  the  members  and  interface 
control  documents,  specifically  as  regards  the  computer  resources. 

(b)  Policies,  procedures,  and  tasks  to  be  Implemented  to  assure 
proper  assessment  and  control  of  computer  resources  and  their  requirement 
both  performance  and  quality,  throughout  the  system  life  cycle. 

h.  Data  management. 

(1)  Computer  resource  documentation  will  include  only  that  documenta 
tlon  required  by  computer  resource  regulations,  standards,  and  management 
policies  and  procedures  that  are  necessary  for  the  disciplined  control  of 
the  development  and  complete  description  of  the  product. 

(2)  Documentation  will  include  both  technical  data  addressing  the 
computer  resource  produce  and  its  support,  management  data  necessary  fo.r 
the  control  of  the  system  development,  and  documentation  acquired  from 
contractors  as  products  of  the  various  life  cycle  phases. 

(3)  Computer  resource  data  management  planning  will  be  addressed  in 
the  CRMP.  Computer  resource  data  management  planning  will  include  those 
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policies  and  procedures  necessary  for  effective  life  cycle  management  of 
data  pertaining  to  the  system's  computer  resources. 

i.  Integrated  Logistics  Support  (1LS).  1LS  is  the  process  through 
which  logistic  considerations  are  integrated  into  the  design  effort  and 
all  elements  of  the  logistic  support  system  are  planned,  acquired, 
tested,  and  deployed. 

(1)  Materiel  developers  will  establish  internal  policy,  procedures, 
and  techniques  for  integrating  life  cycle  logistic  support  considerations 
into  the  Army's  battlefield  systems  for  computer  resources,  under  the 
provisions  of  AR  700-127  and  DARCOM  Supplement  1  thereto. 

(2)  The  materiel  developers,  in  coordination  with  the  combat 
developers  and  training  and  support  elements,  will  determine  overall 
aspects  of  the  ILS  concept  for  computer  resources.  In  establishing  the 
ILS  concept  for  computer  resources,  the  following  will  be  considered: 

(a)  Current  and  proposed  changes  in  maintainability,  supply  and 
maintenance,  doctrine,  concepts,  organization,  and  procedures,  applicable 
to  the  anticipated  environment  for  the  computer  resources. 

(b)  Use  of  common  computer  support  software  and  test  facilities  for 
use  during  all  phases  of  system  acquisition. 

(c)  The  identification  of  appropriate  support  parameters,  life  cycle 
support  cost  goals,  and  limits  on  the  requirements  for  logistic 
resources. 

(d)  Identification  of  qualitative  and  quantitative  personnel 
requirements  information. 

(e)  Establishment  of  procedures  for  the  use  of  computer  assisted 
repair  part  maintenance  and  diagnostics. 

(f)  Development  of  support  software. 

(g)  Estimation  of  life  cycle  operating  and  support  costs  for 
computer  resources,  and  their  inclusion  in  total  system  life  cycle  cost 
assessments. 

(h)  Refinement  and  evaluation  of  alternative  computer  resource 
logistic  support  concepts  and  establishment  of  the  selected  baseline 
support  concepts. 
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(i)  Documentation  of  the  results  of  computer  resource  logistics 
planning  and  analysis  by  updating  the  computer  resource  portion  of  the 
Plan  for  Support,  section  VI  of  the  Acquisition  Plan. 

(j)  Analysis  of  the  supportability  of  firmware/software  requirements 
in  terms  of  possible  enhancements  or  requirements  changes. 

(k)  Assurance  of  the  sufficiency  of  technical  publications  necessary 
to  operate,  maintain,  and  train  for  the  operational  computer  programs 
(and  their  support  computer  programs),  Automatic  Test  Equipment  (ATE) 
computer  programs,  and  training  computer  programs. 

(l)  Planning  for  post  deployment  software  support  will  be  initiated 
prior  to  Milestone  II.  Support  software  as  deliverables  will  be  specified 
prior  to  entering  the  Full-Scale  Engineering  Development  Phase.  Newly 
developed  support  software  documentation  will  comply  with  MIL-STD-490. 
Existing  support  software  should  meet  good  commercial  documentation 
practices.  The  CRMP  will  address  the  post  deployment  issue  and  will 
Include  an  estimate  of  the  resources  for  support  equipment,  applications 
software,  software  support,  and  personnel  required  to  maintain/modify  the 
fielded  system.  The  organization  responsible  for  post  deployment  soft¬ 
ware  support  will  also  be  identified  at  this  time.  The  software  support 
facility  will  be  responsible  for  maintaining  a  software  malfunction 
reporting  system  for  assessing  software  performance  and  determining 
necessary  modifications.  The  CRMP  will  also  address  software  changes 
during  the  post  deployment  phase  and  discuss  the  methods  to  be  used  for 
validation  to  the  satisfaction  of  the  user  prior  to  any  release  for  field 
usage. 

(3)  The  logistic  support  of  computer  resources  will  be  included  as  a 
topic  of  major  importance  at  each  Logistic  Command  Assessment  of  Projects 
(LOGCAP)  briefing/reviews  (DARCOM-R  1-41  and  DARCOM  Supplement  1  to  AR 
700-127). 

j.  Training.  Planning  for  training  of  personnel  to  operate,  test, 
maintain,  and  modify  computer  resources  will  be  initiated  early  in  the 
system  life  cycle.  The  CRMP  will  address  all  aspects  of  personnel 
training  involving  computer  resources.  Maximum  consideration  will  be 
made  to  use  the  system  computer  resources  for  training  in  the  field  and 
in  garrislon. 

k.  Personnel.  Personnel  requirements  for  all  DARCOM  organizations 
directly  Involved  In  the  development  and  support  of  computer  resources 


124 


DARCOM-R  70-16 


for  the  system  will  be  identified  in  the  CRMP.  As  a  minimum,  this  should 
cover  the  project  office  and  training,  operation,  maintenance,  test, 
configuration  management,  and  post  deployment  support  activities. 

Separate  estimates  will  be  made  for  military,  civilian,  and  contractor 
personnel  for  the  development  and  support  phases. 

l.  Deployment  planning.  A  materiel  fielding  plan  will  be  prepared 
that  includes  a  complete  system  description,  logistic  support  management, 
system  support  details  including  the  maintenance  concept  and  integrated 
logistics  support,  and  support  required  from  the  gaining  command 
including  communication  requirements,  necessary  to  deploy  and  support  the 
system  in  any  tactical  environment. 

m.  Compatibility  and  interoperability. 

(1)  Compatibility  and  interoperability  requirements  of  Army  battle¬ 
field  automated  systems  which  include  computer  resources  will  be 
addressed  throughout  the  system's  life  cycle.  There  will  always  be  a 
continuum  of  Army  battlefield  automated  systems,  for  which  interopera¬ 
bility  requirements  have  been  identified,  existing  in  all  phases  of  the 
system  acquisition  process.  A  similar  continuum  of  communications 
necessary  to  support  these  Army  battlefield  automated  systems  will  also 
exist.  A  highly  coordinated  management  effort  is  crucial  to  Insure  the 
concurrent  availability  of  the  Army  battlefield  automated  systems  for 
which  interoperability  requirements  and  supporting  communications  systems 
requirements  are  met.  Systems  planning  and  development  must  also  be 
consistent  with  joint  and  allied  forces  requirements  for  Interoperability, 
compatibility,  and  Integration  of  Army  battlefield  automated  system 
concepts,  operating  procedures,  software  programs,  and  communications, 
including  those  systems  that  interact  and  operate  with  other  services  or 
allied  forces  systems. 

(2)  Army  battlefield  automated  systems  compatibility  and  interopera¬ 
bility  requirements  will  be  defined,  developed,  and  tested  as  an  Integral 
part  of  the  life  cycle  system  acquisition  process.  The  combat  developer 
will  identify  potential  Army  battlefield  automated  system  compatibility 
and  interoperability  requirements  in  the  initial  requirements  document, 
e.g. ,  MENS,  LOA,  LR,  or  ROC.  This  will  include  potential  joint  and 
friendly  forces  systems  requirements,  as  well  as  intra-Army  system 
requirements. 

(3)  For  those  Army  battlefield  automated  systems  that  Include 
computer  resources,  the  Computer  Resource  Working  Group,  in  coordination 


125 


DARCGM-R  70-16 

with  representatives  of  other  services  or  friendly  forces  as  applicable, 
will  develop  as  a  part  of  the  system  CRMP  the  interoperability,  compat¬ 
ibility,  and  communications  requirements  and  identify  the  resources  and 
schedules  necessary  for  their  effective  development,  Implementation,  and 
support. 

(4)  The  materiel  developer,  in  coordination  with  the  combat 
developer,  will  insure  that  all  Army  systems  for  which  interoperability 
requirements  have  been  identified  are  included  in  the  overall  Army 
Interoperability  Plan  (AIP)  and  will  recommend  to  HQ,  DARCOM  those 
systems  that  must  be  Included  in  joint  or  friendly  forces  interopera¬ 
bility  programs.  The  materiel  developer  will  insure  that  interopera¬ 
bility  resource  requirements  of  interfacing  systems,  to  include  the 
supporting  communications,  are  properly  coordinated  during  system 
development,  and  that  system  interoperability  is  tested  and  verified 
prior  to  request  for  production  decision. 

(5)  Interoperability  plans  will  be  included  in  operational  tests  and 
will  be  reviewed  at  Milestones  II  and  III. 

(6)  Technical  and  operational  interoperability  configuration  control 
for  Army  battlefield  automated  systems  is  the  responsibility  of  the 
materiel  developer  in  coordination  with  the  combat  developer  for  Intra- 
Army  systems  and  as  designated  by  appropriate  authority  for  joint  or 
friendly  force  systems. 

n.  Validation  and  verification.  The  primary  objective  of  the 
computer  resources  requirements  validation  efforts  is  to  insure  that  the 
stated  requirements  for  total  computer  resources  generated  during  the 
Demonstration  and  Validation  phase  are  complete,  consistent,  and  unam¬ 
biguous,  and  will  result  in  a  system  that  meets  the  stated  operational 
needs  of  the  user  and  can  be  supported  in  the  field.  The  computer 
resource  related  technical,  cost  schedule,  and  performance  risks 
associated  with  the  system  as  based  on  the  stated  and  validated  computer 
resource  requirements,  will  be  addressed  in  the  CRMP.  The  verification 
of  computer  resource  requirements  will  include  necessary  planning 
and  execution  by  the  materiel  developer  of  those  monitoring  and  test 
activities  that  will  ascertain  that  the  system  fulfills  the  stated 
requirements.  Included  will  be  sufficient  tests,  through  simulation  and 
actual  executions,  to  determine  that  the  system  performs  correctly 
against  the  previously  validated  requirements. 

2-5.  Standards,  a.  General:  Computer  resource  management  standards 
such  as  MIL-STD,  FIPS,  FED  STD,  and  approved  nongovernment  standards. 
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for  measuring  software  performance  shall  be  adopted  on  a  project  by 
project  basis  by  the  materiel  developer.  These  standards  are  categorized 
in  subsequent  paragraphs. 

b.  Computer  resource  planning  standards.  These  standards  shall 
provide  specific  detailed  guidance  for  developing  and  maintaining  the 
CRMP  throughout  the  life  cycle. 

c.  Specification  standard.  These  standards  shall  provide  guidance 
on  the  format,  structure,  and  content  of  computer  program  functional  and 
performance  speclficaton  (TYPE  A  System  Specification),  computer  program 
development  specifications  (TYPE  B-5  Development  Specification),  and 
computer  program  product  specifications  (TYPE  C-5  Product 
Specification). 

d.  Documentation  standards.  These  standards  shall  specify  the 
structure  and  content  of  the  external  documentation  set.  They  shall 
provide  standards  and  guidance  for  developing  and  maintaining  the  soft¬ 
ware  documentation  set,  and  define  in  detail  the  specific  content  of  each 
document  required,  and  how,  when,  and  where  it  should  be  produced  through¬ 
out  the  life  cycle. 

e.  Programing  standards.  These  standards  shall  provide  guidance 
for  writing  and  maintaining  computer  programs.  Standards  for  specific 
languages  will  include  rules  to  be  followed  when  writing  programs  in  that 
language. 

f.  Quality  control  standards. 

(1)  Testing  standards.  These  standards  shall  provide  guidance  for 
the  development  and  maintenance  of  software  test  facilities  and  instru¬ 
mentation  to  be  used  during  development  and  validation  of  changes 
throughout  the  system  life  cycle. 

(2)  Configuration  management  standards.  These  standards  shall  provide 
guidance  for  the  implementation  and  control  of  configuration  management 
practices  as  they  apply  to  software  driven  systems.  They  shall  also 
provide  policies  and  procedures  for  maintenance,  refinement,  and  enhance¬ 
ment  of  a  system  that  is  in  production  at  multiple  installations  that  are 
geographically  separated. 
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Appendix  A 
EXPLANATION  OF  TERMS 


A-l.  ARMY  BATTLEFIELD  AUTOMATED  SYSTEM.  A  system  employing  computer 
resources  that  operates  or  has  components  that  operate  within  the 
boundaries  of  the  battlefield  regardless  of  the  function,  mission,  or 
battle  Involvement.  The  system  may  be  an  offensive,  defensive,  or  direct/ 
indirect  support  system.  Examples  of  such  systems  are  weapons,  communica¬ 
tions,  command  and  control,  intelligence,  avoinics,  missiles,  combat 
support,  and  combat  service  support  systems. 

A-2.  AUTOMATIC  DATA  PROCESSING  EQUIPMENT  (ADPE).  This  includes  general 
purpose  electronic  data  processing  equipment  (EDPE)  and  punch  card 
machines  (PCM  or  EAM)  irrespective  of  use,  application,  or  source  of 
funding,  and  includes  ADPE  built  to  Government  specifications. 

A-3.  CCMBAT  DEVELOPER.  The  agency  or  command  responsible  for  the 
formulation  of  concepts,  doctrine,  organization  and  materiel  objectives, 
and  requirements  for  the  employment  of  US  Army  Forces  in  a  theater  of 
operations  and  in  the  control  of  civil  disturbances.  The  combat 
developer  formulates  Army  functional  systems  (logistics,  personnel, 
administrative,  and  others,  as  designated)  which  impact  directly  on  or 
extend  into  a  theater  of  operations.  The  US  Army  Training  and  Doctrine 
Command  (TRADOC)  is  the  Army ’s  principal  combat  developer. 

A-4.  COMPUTER.  Electronic  machinery,  which  by  means  of  stored 
instructions  and  data  performs  rapid  complex  calculations  or  compiles, 
correlates,  and  selects  data.  Examples  are  analog  and  digital 
processors,  data  processors,  Information  processors,  real-time  control 
processors,  electronic  calculators,  hybrid  computers,  communications 
processors,  and  microprocessors. 

A-5.  COMPUTER  DATA.  A  representation  of  facts,  concepts,  or  instruc¬ 
tions  in  a  structured  form  suitable  for  acceptance,  interpretation,  or 
processing  by  communication  between  computer  equipment.  Such  data  can  be 
external  to  (in  computer-readable  form)  or  resident  within  the  computer 
equipment  and  can  be  in  the  form  of  analog  or  digital  signals. 

A-6.  COMPUTER  EQUIPMENT/ COMPUTER  HARDWARE.  Devices  capable  of  accepting 
and  storing  computer  data,  executing  a  systematic  sequence  of  operations 
on  computer  data  or  producing  computer  outputs.  Such  devices  can  perform 
substantial  interpretation,  computation,  communication,  control,  or  other 
logical  functions.  Examples  are  central  processing  units,  terminals, 
printers,  analog/digital  converters,  tape  drives,  disks,  drums,  micro¬ 
processors,  and  automatic  test  equipment. 
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Appendix  A — Continued 

A-7.  COMPUTER,  GENERAL  PURPOSE.  A  computer  designed  to  solve  a  large 
variety  of  problems,  e.g.,  a  stored  program  computer  that  may  be  adapted 
to  any  of  a  very  large  class  of  applications. 

A-8.  COMPUTER  FIRMWARE.  Programs  or  instructions  that  are  stored  in 
read  only  memory;  firmware  is  analogous  to  software  in  unalterable  form. 

A-9.  COMPUTER  PROGRAM.  A  series  of  instructions  or  statements  in  a  form 
acceptable  to  computer  equipment,  designed  to  cause  the  computer  equip¬ 
ment  to  execute  an  operation  or  operations.  Computer  programs  include 
operating  systems,  assemblers,  compilers,  interpreters,  data  management 
systems,  utility  programs,  sort-merge  programs,  and  maintenance/diagnostic 
progiams,  as  well  as  applications  programs  such  as  payroll,  inventory 
coi.trol,  operational  flight,  satellite  navigation,  automatic  test,  crew 
simulator,  and  engineering  analysis  programs.  Computer  programs  may  be 
general-purpose  in  nature  or  be  designed  to  satisfy  the  requirements  of  a 
specialized  process  or  a  particular  user. 

A- 10.  COMPUTER  RESOURCES.  The  totality  of  computer  equipment,  computer 
programs,  computer  data,  associated  computer  documentation,  contractual 
services,  personnel,  and  computer  supplies. 

A— 11.  COMPUTER  SOFTWARE.  A  combination  of  associated  computer  programs, 
documentation  and  computer  data  required  to  command  the  computer  equip¬ 
ment  to  perform  computational  or  control  functions. 

A- 12.  COMPUTER  SOFTWARE  DOCUMENTATION.  Technical  data,  including  com¬ 
puter  listings  and  printouts  in  human-readable  form,  that  documents  the 
design  or  details  of  computer  software,  explains  the  capabilities  of  the 
computer  software,  or  provides  operating  instructions  for  using  the  com¬ 
puter  software  to  obtain  desired  results  from  computer  equipment.  For 
the  purposes  of  documentation,  the  term  software  includes  all  informa¬ 
tion,  data,  analysis,  algorithms,  etc.,  that  have  been  generated,  ac¬ 
quired,  or  applied  in  developing  computer  programs  for  the  system  and 
system  support  equipment.  This  includes  specifications,  functional 
descriptions,  design  analysis,  program  coding,  flow  charts,  algorithms. 
Interface  definitions,  technical  manuals,  source  and  object  decks  and 
listing,  test  plans/procedures/reports,  and  support  programs  and  their 
documentation. 


A-13.  COMPUTER  SYSTEM.  An  interacting  assembly  consisting  of  computer 
equipment,  computer  programs,  and  computer  data. 
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Appendix  A— Continued 

A-14.  COMPUTER  SYSTEM  DOCUMENTATION.  Information  that  describes  the  tech¬ 
nical  details  of  the  computer  system  over  its  life  cycle.  Documentation 
includes,  but  is  not  limited  to,  equipment  design  specifications,  engineering 
drawings,  operators  manuals,  technical  orders,  computer  software  documenta¬ 
tion,  systems  specifications,  run  diagrams,  and  interface  specifications. 

A-15.  CONFIGURATION  ITEM  (Cl).  An  aggregation  of  hardware/software,  or 
any  of  its  discrete  portions,  that  satisfies  an  end  use  function  and  is 
designated  by  the  Government  for  configuration  management.  Cl's  may  vary 
widely  in  complexity,  size,  and  type  from  an  aircraft,  electronic,  or 
ship  system  to  a  test  meter  or  round  of  ammunition.  During  development 
and  initial  production.  Cl's  are  only  those  specification  items  that  are 
referenced  directly  in  the  contract  (or  an  equivalent  in-house  agreement). 
During  the  operation  and  maintenance  period,  any  repairable  items  desig¬ 
nated  for  separate  procurement  is  a  configuration  item  (DOD  Directive 
5010.19). 

A-16.  EMBEDDED  COMPUTER  RESOURCES.  The  totality  of  computer  resources 
that  form  a  subsystem  or  part  of  an  Army  battlefield  automated  system 
e.g. ,  intelligence  collection  system,  target  acquisition  system,  or 
weapon  system.  (For  the  purposes  of  this  regulation  the  term  "Embedded 
Computer  Resource"  is  replaced  by  "Army  battlefield  automated  system"  as 
defined  in  para  A-l.) 

A-17.  INDEPENDENT  ASSESSMENT.  The  assessment  of  a  system  or  subsystem 
by  an  organization  that  is  independent  of  the  combat  developer  and  the 
materiel  developer. 

A— 18.  INDEPENDENT  EVALUATION.  The  evaluation  of  a  system  or  subsystem 
by  an  organization  that  is  independent  of  the  combat  developer  and  the 
materiel  developer. 

A-l 9.  INTERNAL  SYSTEM  CONTROL.  Any  device(s)  automatic  or  manual,  that 
controls  the  operation  of  a  system  without  external  stimulus. 

A- 20.  MATERIEL  DEVELOPER  (OR  DEVELOPING  AGENCY).  The  command  or  agency 
responsible  for  research,  development,  and  production  validation  of  an 
item  (Including  the  system  for  its  logistic  support)  which  respond  to  DA 
objectives  and  requirements  (table  6-1,  AR  70-1). 

A- 21.  FIRST  ARTICLE  TEST.  That  test  and  evaluation  of  production  items 
to  demonstrate  that  items  delivered  fulfill  the  requirements  and  specifi¬ 
cations  of  the  production  contract  or  agreement. 

A-22.  SOFTWARE  QUALITY.  Attributes  of  a  software  package  other  than 
performance  requirements  that  indicate  the  character  of  the  software; 


. 

■  •  •  , 
«  f-A  1»>  fc 


131 


DARCOM-R  70-16 


Appendix  A — Continued 

usually  defined  in  terms  of  quality  factors,  e.g. ,  correctness, 
reliability,  acceptability,  flexibility,  efficiency,  human  factors 
engineering,  integrity,  and  testability. 

A-23.  SYSTPl  ACQUISITION  PLAN.  Tb-v  basic  management  document  for  all 
Army  materiel  acquisition  programs  upported  by  an  approved  materiel 
requirement,  regardless  of  the  level  or  the  MADP  review/approval. 
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COMPUTER  RESOURCE  MANAGEMENT  PLAN  (CRMP) 


Development  of  the  Computer  Resource  Management  Plan  (CRMP)  will  begin  as 
soon  as  it  is  determined  that  computer  resources  will  be  used  to  support 
the  satisfaction  of  stated  system  functional  requirements.  The  CRMP  will 
be  an  annex  to  the  System  Acquisition  Plan  and  will  consist  of  six 
sections  as  follows: 

Related  Sections 

_ CRMP _ of  Acquisition  Plan 


Section  I 
Section  II 
Section  III 
Section  IV 
Section  V 
Section  VI 


General 

Program  Management 
Acquisition  Management 
Development  Management 
Coordinated  Test  Program  Mgt 
Plan  for  Support 


Section  I 
Section  III 
Section  III 
Section  III 
Section  IV 
Section  VI 


B— 1.  Section  I,  General.  This  section  will  provide  an  overview  of  the 
overall  system  requirement  and  the  relationship  thereto  of  the  proposed 
computer  resources.  Any  unique  operational  or  technical  system  require¬ 
ment  that  could  affect  the  development  or  use  of  the  proposed  computer 
resources  should  be  indicated. 


B-2.  Section  II,  Program  Management.  This  section  will  be  prepared 
immediately  upon  the  determination  that  computer  resources  are  required 
in  the  system.  This  would  normally  occur  during  the  Demonstration  and 
Validation  phase.  It  is  to  address  the  organizations  and  personnel 
involved  in  the  management  of  computer  resources.  As  a  minimum,  this 
section  will  contain: 


a.  Identification  of  computer  resources  technical  and  managerial 
expertise  responsible  to  the  program  manager  for  managing  the  acquisition 
of  subsystems  that  contain  computer  equipment  and  computer  programs.  This 
includes  management  expertise  to  focus  attention  on  computer  program 
development  and  integration  across  the  total  system. 

b.  Identification  of  management  responsibility  for  the  Integration 
of  computer  equipment  and  programs  with  the  rest  of  the  system. 

c.  Identification  of  computer  programs  development  and  support 
requirements,  including  use  of  Government-funded  equipment  and  facilities. 
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d.  The  extent,  within  each  system  as  well  as  across  systems,  to 
which  computer  equipment  and  computer  programs  will  be  standardized. 

e.  A  plan  for  development  and/or  modification  of  computer  software 
or  equipments  covering  definition  of  requirements,  development,  audits, 
testing,  and  maintenance. 

f.  Plans  and  justification  for  acquisition  of  any  support  equipment 
(e.g. ,  a  simulation  facility)  that  is  required. 

g.  A  plan  for  the  functional  analysis  and  trade-off  studies  to  be 
employed  to  minimize  risk  in  the  development  of  computer  equipment  and 
computer  software. 

h.  An  indication  of  the  extent  to  which  existing  systems,  existing 
eqi  ipments  and  proven  concepts  will  be  used. 

i.  An  evaluation  of  the  systems  capacity  to  provide  for  growth  con¬ 
sistent  with  anticipated  change  to  the  system  capabilities  and  an  indica¬ 
tion  of  the  resources  required  for  and  risk  associated  with  computer  pro¬ 
gram  support  throughout  the  system  life  cycle. 

j.  Identification  of  projected  computer  equipment  and  computer  pro¬ 
gram  development  costs,  including  appropriate  work  breakdown  structures. 

B-3.  Section  III,  Acquisition  Management.  This  section  will  be  prepared 
during  the  Demonstration  and  Validation  phase.  It  will  address  the 
computer  resource  acquisition  strategy,  the  participation  of  the  combat 
developer,  materiel  developer,  development  and  operational  testers  and 
evaluators,  and  designated  post  deployment  support  activities,  the  risks 
involved,  and  trade-offs  to  be  considered.  In  addition^ it  will  address 
the  adequacy,  consistency,  and  firmness  of  requirements  driving  the 
computer  resource  development.  This  section  is  prepared  by  the  materiel 
developer  in  coordination  with  the  aforementioned  participating  commands 
and  activities.  It  includes  complete  management  planning  for  the  acqui¬ 
sition  and  support  of  the  computer  resources.  If  additional  computer 
resources  are  identified  later  in  the  program,  a  change  to  this  section 
will  be  published  covering  such  resources.  As  a  minimum,  this  section 
will  contain: 

a.  Identification  of  technical  and  managerial  expertise  allocated  to 
the  program  office  for  the  acquisition  management  of  computer  equipment 
and  computer  programs. 
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b.  Operational  and  support  concepts  for  computer  programs  based  upon 
studies,  economic  analyses,  experience,  and  participating  activity  inputs. 

c.  The  system  engineering  approach  to  be  followed  in  allocation  of 
operational  needs  to  computer  resources. 

d.  A  discussion  of  the  appropriate  trade-offs  between  hardwired 
digital  processing  equipment  and  programmable  computer.  The  discussion 
should  include  design  risk,  system  integrity,  and  life  cycle  cost. 

e.  Standardization  and  commonality  considerations  used  in  determining 
computer  equipment  and  computer  program  requirements. 

f.  Requirements  for  computer  program  and  data  rights  consistent  with 
the  planned  operational  and  support  concepts. 

g.  A  master  schedule  of  major  milestone,  key  events,  and  any 
critical  actions  essential  to  timely  development  of  computer  resources  in 
relation  to  the  total  system  acquisition  schedule  and  identified  risk 
areas. 

h.  Identification  of  required  interfaces  between  the  computer 
resources  of  the  system  and  other  systems. 

i.  Identification  of  the  requirements  for  growth  capability  and 
spare  processing  capacity. 

j.  Requirements  for  acqusition  and  support  of  documentation. 

k.  Requirements  for  simulation,  integration,  and  other  facilities 
necessary  to  support  computer  programs. 

l.  Configuration  management  concepts  for  the  system;  computer  hard¬ 
ware;  support,  diagnostic  and  application  software;  and  intersystem 
interfaces. 

m.  Criteria  for  the  transfer  of  program  management  responsibility 
and  system/equipment  turnover  and  support. 

B-4.  Section  IV,  Development  Management.  This  section  will  be  prepared 
during  the  Demonstration  and  Validation  phase.  It  will  address  the 
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approach  for  the  development  of  computer  resources,  tools  to  be  used, 
necessary  facilities,  and  cost  and  schedules.  This  section  will  identify 
the  actions  necessary  for  the  development  and  delivery  of  computer  pro¬ 
gram  configuration  items  and  necessary  support  resources.  It  is  prepared 
by  the  materiel  developer  or  his  contractor.  Supporting  detail  will 
appear  in  the  Acquisition  Plan  (see  AR  70-27).  As  a  minimum,  this 
section  will  contain: 

a.  The  organization,  responsibilities,  and  structure  of  the  group(s) 
that  will  be  designing,  producing,  and  testing  all  computer  programs. 

b.  The  management  and  technical  controls  that  will  be  used  during 
the  development,  including  controls  for  insuring  that  all  performance  and 
design  requirements  have  been  implemented. 

c.  The  methodology  for  insuring  satisfactory  design  and  testing, 
including  quality  assurance. 

d.  The  development  schedule  for  each  computer  program  configuration 
item  and  proposed  program  milestone  review  points. 

e.  The  procedure  for  monitoring  and  reporting  the  status  of  computer 
program  development. 

f.  The  resources  required  to  support  the  development  and  test  of 
computer  programs.  Special  simulation,  data  reduction,  or  utility  tools 
that  are  planned  for  use  in  the  development  of  computer  programs  should 
be  identified. 

g.  The  general  procedures  for  reporting,  monitoring,  and  resolving 
computer  program  errors  and  deficiencies  during  development  and  testing. 

h.  The  methods  and  procedures  for  collecting  data,  analyzing,  moni¬ 
toring,  and  reporting  on  the  timing  of  time  critical  computer  programs. 

i.  The  management  of  previous,  current,  and  proposed  versions  of 
computer  program  masters,  data  bases,  and  associated  documentation, 
including  their  relationship  to  the  configuration  management  plan. 

j.  Guidelines  and  checkpoints  for  insuring  future  computer  program 
growth,  modularity,  and  ease  of  modification. 
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k.  The  approach  for  developing  computer  program  documentation. 

l.  Training  requirements  and  associated  equipment  for  the  deploy¬ 
ment  phase. 

m.  Engineering  practices  to  include:  standards,  conventions,  pro¬ 
cedures,  rules  for  program  design,  program  structures  and  conventions, 
display  and  logic  standards,  input /output  signal  standards,  and  other 
disciplines  affecting  development. 

n.  Security  controls  and  requirements. 

o.  Simulation  techniques  and  tasks. 

p.  Schedule  and  description  of  the  technical  milestones  listed  in 
paragraph  2-2. b. (3). 

B-5.  Section  V,  Coordinated  Test  Program  Management,  a.  This  section 
will  address  the  issue  of  the  management  of  the  test  and  evaluation  of 
computer  resources  in  the  system.  It  will  contain  a  plan  and  schedule 
for  development  of  test  plans  for  testing,  validation,  and  verification. 

b.  Preparation  of  this  section  will  be  by  the  Test  Integrated  Work¬ 
ing  Group  (TIWG)  during  the  Demonstration  and  Validation  phase.  Support¬ 
ing  data  will  appear  in  the  Coordinated  Test  Program  (see  AR  70-10  and  DA 
PAM  70-21). 

c.  As  a  minimum,  this  section  will  contain: 

(1)  The  responsibilities  and  interrelationships  among  the  combat 
developer,  materiel  developer,  contractor,  developmental  and  operational 
testers  and  evaluators,  and  designated  post  deployment  support  activities 
during  the  various  levels  of  software  testing. 

(2)  The  identification  of  the  organizations  or  activities  responsi¬ 
ble  for  the  independent  software  testing  (validation  and  verification). 

(3)  The  development/acquisition  schedule  for  any  special  test  tools 
required,  e.g. ,  driver,  monitors,  emulators,  and  whether  they  will  be 
Government -furnished  or  contractor. developed. 

(4)  The  schedule  for  the  development  and  use  for  simulation  models 
(Functional  System,  Computer  System  and  Engineering  Models). 
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(5)  Test  requirements  analysis*  methodology  and  associated 
schedules. 

(6)  Methodo.ogy  and  schedule  for  the  development  of  Benchmark  Test 
Cases  for  the  various  levels  of  software  testing. 

(7)  The  software  monitoring  design  plan. 

(8)  Procedures  for  reporting  and  resolving  computer  program  errors 
and  deficiencies  during  testing. 

(9)  Plan  tor  the  conduct  of  the  supportability  demonstration  of  the 
post  d  ‘ployment  software  support  facilities.  The  supportability 

demo  cration  plan  will  delineate  and  specify  the  requirements  for  the 
testing  procedures,  internal  and  external  interfaces,  equipment,  and 
crsonnel  as  well  as  the  methodology  to  be  used  to  verify  compliance  with 
_he  requirements.  The  plan  should  exercise  the  support  capability  in 
real-time  to  permit  assessment  and  certification  of  its  adequacy  for  the 
post  deployment  phase. 

(10)  Schedules  for  test  plans  and  testing. 

B-6.  Section  VI,  Plan  for  Support.  This  section  will  address  the  Issues 
of  computer  resource  supportj  particularly  software  support  after 
deployment  and  will  be  prepared  by  the  materiel  developer  during  the 
demonstration  and  validation  phase.  The  organizational  relationships  and 
responsibilities  for  the  management  and  technical  support  of  computer 
resources  will  be  identified.  This  section  identifies  the  computer 
resources  necessary  to  support  computer  programs  after  transfer  of 
program  management  responsibility  to  the  receiving  readiness  command  and 
system  deployment  to  the  field.  This  section  also  addresses  the  basic 
agreements  between  the  supporting  and  using  commands  for  management  and 
support  of  computer  resources.  The  following  items  should  be  included, 
as  applicable: 

a.  Offices  of  primary  responsibility  and  management  focal  points  for 
support  of  computer  resources  and  the  channels  of  communication  among 
organizations. 

b.  Planning  for  the  configuration  management  of  computer  programs, 
including  the  assignment  of  configuration  control  responsibilities  dur¬ 
ing  the  deployment  phase.  This  planning  will  reflect  the  operational 
and  support  concepts  for  the  system. 
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c.  Responsibilities  for  composite  system  integrity  that  includes: 

(1)  Computer  storage  use. 

(2)  Computer  program  operating  time  and  priorities. 

(3)  Computer  program  interface  techniques. 

(A)  Computer  program  baseline  integrity. 

(5)  Use  of  computer  modules  and  peripherals. 

d.  Documentation  required  to  support  each  type  of  computer  program. 

e.  Responsibility  for  funding,  scheduling,  and  system  integration. 

f.  Qualified  personnel  required  for  supporting  computer  equipment 
and  computer  programs  together  with  associated  training  requirements. 

g.  Computer  equipment  and  devices  required  to  facilitate  computer 
program  changes,  including  acquisition  responsibilities. 

h.  Computer  programs  required  to  support  computer  equipment  and 
other  computer  programs,  including  acquisition  responsibilities. 

i.  Verification  and  validation  of  computer  programs. 

j.  Plans  to  establish  and  operate  necessary  support  facilities. 
Common  and  existing  facilities  will  be  used  whenever  practicable.  The 
size  and  scope  of  the  support  facility  will  be  based  on  workload 
predictions. 

k.  Provisions  for  the  transfer  of  program  management  responsibility. 

l.  Provisions  for  system/equipment  deployment. 
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SYSTEM  ACQUISITION  REVIEWS 


The  following  questions  concerning  the  management  of  computer  resources 
are  applicable  to  the  development  and  acquisition  of  all  Army  battlefield 
systems  that  Include  computer  resources.  The  questions  supplement  the 
milestone  checklists  in  AR  15-14. 

C-l.  Milestone  I  Reviews,  a.  General. 

(1)  What  steps  are  being  made  to  Insure  software  visibility? 

(2)  What  other  computer/communication  systems  will  the  system  have 
to  Interface  with?  Is  enough  known  about  these  other  systems  to  allow 
design  for  Interoperability? 

b.  Operational  requirements.  When  will  a  validation  of  the  computer 
resources  requirements,  including  software,  be  conducted?  How  will  the 
risk  analysis  be  performed? 

c.  Life  cycle  management. 

(1)  How  will  post  deployment  support  be  handled  (by  contractor  or 
Government  personnel)?  When  will  the  system  life  cycle  support  activity 
be  designated?  Who  is  the  designated  system  life  cycle  support  activity? 

(2)  Will  Operating  and  Maintenance,  Army  (OMA)  funds  be  requested  to 
support  contractor  activities  directed  toward  providing  maintenance 
capabilities  and  documentation?  How  will  maintenance  provisions  be 
specified?  When?  How  will  support  requirements  be  determined? 

(3)  Is  any  computer  hardware  unique?  If  so,  how  will  replacement 
parts  be  obtained? 

d.  Tradeoffs. 

(1)  How  will  hardware/software  tradeoffs  be  made? 

(2)  How  will  the  processor  architecture  be  determined? 

(3)  How  will  the  processor  capacity  be  determined? 
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(4)  How  will  excess  memory,  processor  time,  and  capability  needs  be 
determined? 

(5)  Will  use  of  computer  reduce  or  increase  personnel  requirements? 

(6)  System  tradeoffs  as  a  result  of  cost-benefit  analysis. 

e.  Use  of  existing  hardware  and  software 

(1)  Can  presently  available  technology  (computer,  sensor,  and 
control)  be  used?  Can  state-of-the-art  technology  be  used?  What  special 
tasks  must  be  performed  in  advanced  development  to  perfect  these  new 
technologies? 

(2)  How  much  of  the  system  design  can  be  obtained  "off-the-shelf"  or 
I laglarized  from  previous  systems? 

f.  Possible  future  problem  areas. 

(1)  Has  preliminary  systems  analysis  been  performed?  What  hardware 
and/or  software  problem  areas  have  been  defined  as  a  result  of  this 
preliminary  analysis?  How  will  they  be  handled  during  advanced  develop¬ 
ment? 

(2)  What  critical  questions  and  areas  of  risk  must  be  resolved 
during  Program  Demonstration  and  Validation  Phase?  What  are  the  test 
objectives  schedules,  and  milestones  to  be  used  to  determine  required 
information? 

(3)  Are  any  risk  areas  envisioned  not  previously  mentioned?  What 
are  your  plans  to  resolve  these  problems? 

(4)  Have  any  system  interfaces  and  supporting  communications 
requirements  been  identified?  Has  coordination  been  effected  to  insure 
the  availability  of  these  interfaces  or  communications? 

C-2.  Milestone  II  Reviews,  a.  Operational  Requirements. 

(1)  Have  the  Type  B-5  Computer  Program  Development  Specifications 
been  completed,  and  is  there  a  cross  reference  of  Operational 
Requirements  to  Computer  Program  Specifications? 

(2)  How  will  the  system  design  be  validated  prior  to  implementation? 


DARCOM-R  70-16 


Appendix  C — Continued 

(3)  Was  the  validation  of  the  computer  resource  requirements, 
including  software,  conducted?  How  was  risk  analysis  performed? 

(4)  How  will  interoperability  and  communications  be  tested? 

(5)  How  will  you  Insure  that  the  planned  computer  resources  will 
meet  stated  operational  requirements? 

b.  Life  cycle  management. 

(1)  How  will  post  development  support  be  handled  (by  contractor  or 
Government  personnel)?  When  will  the  system  life  cycle  support  activity 
be  designated? 

(2)  Will  OMA  funds  be  requested  to  support  contractor  activities 
directed  toward  providing  maintenance  capabilities  and  documentation?  How 
will  maintenance  provisions  be  specified?  When?  How  will  support 
requirements  be  determined? 

(3)  Is  any  computer  hardware  unique?  If  so,  how  will  replacement 
parts  be  obtained? 

(4)  What  steps  have  been  planned  for  the  software  "turnover”  from 
the  contractor  to  the  Government? 

(5)  How  will  the  computer  resources  be  integrated  into  the  total 
battlefield  system? 

(6)  Were  personnel  requirements  for  developing  and  supporting 
computer  resources  determined? 

(7)  What  major  computer  programs  are  required  to  support  the 
development,  acquisition,  and  maintenance  of  computer  equipment? 

(8)  What  software  support  items  will  be  required  for  production  and 
maintenance  of  the  system?  Are  they  specified  as  deliverable? 

c.  Tradeoffs. 

(1)  Were  the  tradeoff  decisions  mentioned  in  Milestone  I  made? 

(2)  What  method  will  be  used  to  measure  memory  use  and  processing 
time? 

(3)  What  cost  benefit  type  trade-offs  are  there? 
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d.  Project  manager's  staff. 

(1)  What  percentage  of  the  development  cost  of  the  project  will  be 
spent  on  computer-related  expenses,  e.g. ,  systems  analysis,  interfacing, 
coding,  debugging,  etc.? 

(2)  How  many  dedicated  project  personnel  are  skilled  in  computers 
and  software?  What  percentage  of  project  staff? 

(3)  How  many  dedicated  project  personnel  have  had  operational 
experience  in  the  project  application  area? 

(4)  What  plans  have  been  made  to  obtain  competent  computer  and  soft 
ware  personnel  on  temporary  assignment  from  service  laboratories  and 
support  activities?  From  contractors? 

(5)  Does  the  Project  Manager  (PM)  have  an  experienced  systems 
engineer  agent  responsible  for  overseeing  software  system  engineering? 

(6)  How  will  the  PM  provide  for  maintenance  support  requirements? 

Is  there  a  dedicated  person  on  the  PM  staff  to  act  as  Software 
Operational  Support  Agent? 

e.  Project  control. 

(1)  What  management  procedures  will  be  used  to  control  software 
development?  How  do  they  monitor  costing  and  scheduling? 

(2)  Have  the  proper  milestones  been  chosen  in  the  management  plan? 
Could  the  failure  to  achieve  a  milestone  be  easily  recognized?  Can  a 
failure  be  anticipated  in  time  to  take  corrective  actions?  Is  the  mile¬ 
stone  schedule  easily  adjusted? 

(3)  Will  there  be  any  parallel  software  development  efforts?  If  so 
how  will  these  efforts  be  controlled? 

(4)  How  will  interface  control  be  conducted?  What  interfaces  e.g., 
intermodule,  intersystem,  etc? 

f.  Development  contract. 

(1)  Will  the  acquisition  take  place  in  acccordance  with  Public  Law 
89-306,  Procurement  of  ADP  Resources  by  the  Federal  Government?  Why  or 
why  not? 


DARCOM-R  70-16 


> 

Appendix  C — Continued 

(2)  Which  type  of  contract  will  be  employed  for  the  software? 

(3)  How  will  the  contractor  be  tasked  for  software  items?  What  will 
be  the  software-related  contractor  incentives? 

(4)  How  will  "negative  software  incentives"  (i.e. ,  simplifying 
hardware  at  the  expense  of  software)  be  handled? 

(5)  Is  all  software  listed  as  configuration  item(s)? 

(6)  Is  all  support  software  listed  as  deliverable?  Is  any  support 
software  proprietary?  If  so,  how  will  this  problem  be  handled? 

g.  Testing. 

(1)  When  will  the  system  and  program  designs  be  frozen? 

(2)  How  will  software  testing  be  performed?  Who  will  generate  the 
test  data?  Have  plans  been  made  to  insure  the  test  data  is  representative 
of  the  total  range  of  data  and  conditions  that  the  system  might  encounter? 
Is  there  a  software  module  test  plan  and  a  software  module  test  procedure? 

(3)  How  is  testing  to  insure  deficiencies  clearly  identified  as 
software  deficiencies  or  hardware  deficiencies?  How  will  the 
determination  of  whether  other  errors  are  caused  by  hardware  or  software 
be  made? 

(4)  Are  "hot  beds"  required  to  adequately  test  software?  Will  they 
become  Government  property  after  testing  is  complete?  If  not,  does  the 
Government  have  equivalent  integration  and  testing  facilities  available? 

(5)  How  will  modules  be  interfaced  with  one  another?  How  will  these 
interfaces  be  tested? 

(6)  What  critical  questions  and  areas  of  risk  still  need  resolving 
by  testing?  What  are  the  test  plans  and  milestones  for  resolving  these 
problems  ? 

(7)  How  will  test  related  documentation  be  maintained  to  allow 
repeatability  of  tests? 

h.  Software  reliability  and  maintainability. 

(1)  Will  a  standard  high  order  language  be  used  for  programming?  If 
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not,  why  not?  What  percentage  of  the  software  will  ultimately  be  written 
in  assembly  language? 

(2)  Will  the  plan  insure  that  the  software  architecture  will  be 
modular  ? 

(3)  Will  the  plan  insure  "top-down"  software  development  methodo¬ 
logy,  and  will  structured  programing  be  used? 

(4)  What  programing  standards  and  conventions  will  be  used?  How 
will  they  be  enforced?  When  will  the  Data  Item  Index  be  prepared  and  how 
will  it  be  updated?  Will  the  plan  insure  that  the  documentation  will  be 
adequate  for  life  cycle  maintenance? 

(5)  which  automatic  debugging  tools  will  be  used  during  program 
develop  ;nent? 

(6)  How  will  error  data  be  collected  and  analyzed? 

(7)  How  will  the  software  be  integrated  with  the  hardware  during 
engineering  development? 

(8)  How  will  software  be  documented  as  it  proceeds  from  concept  to 
design  to  final  operational  system  (e.g. ,  module  specifications  document, 
"design  to"  document,  "as  built"  document,  etc.)? 

(9)  How  will  the  software  be  supported  in  the  field?  What  hardware 
and  software  will  be  needed  for  the  Support  Base?  How  will  it  be 
procured? 

(10)  Will  the  plan  insure  accuracy  of  coding  to  available  listings? 

i.  Miscellaneous. 

(1)  What  has  contractor  done  of  a  similar  nature  in  the  past?  What 
were  his  successes  and  failures?  What  is  he  doing  to  eliminate  past 
problem  areas?  What  are  his  "lessons  learned"? 

(2)  What  issues  must  be  resolved  prior  to  Milestone  III  that  have 
not  already  been  discussed?  What  is  your  plan  to  resolve  them? 

C-3.  Milestone  III  Reviews,  a.  Present  status. 
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(1)  Are  any  software  modules  incomplete?  Which  modules  and  associ¬ 
ated  hardware  are  involved?  What  is  extent  of  incompleteness  and  the 
schedule  for  completion? 

(2)  What  is  the  profile  of  the  last  3  month's  software  discrepancy 
forms  and  software  change  requests?  How  many  discrepancies  are  still  to 
be  corrected?  How  was  error  data  collected  and  analyzed? 

(3)  How  much  of  the  recent  software  change  activity  has  been 
corrective  actions  and  how  much  was  caused  by  change  in  requirements? 
Were  changes  in  requirements  due  to  increased  requirements  or  due  to 
reduced  requirements?  Who  has  the  authority  to  change  software 
requirements? 

(4)  How  has  delivered  code  been  verified  to  conform  to  original 
software  design?  Who  prepared  test  data  for  the  verification?  How  has 
delivered  code  been  shown  to  satisfy  original  operational  requirements? 

(5)  How  was  hardware /software  integration  and  validation  performed? 

(6)  What  is  the  accuracy  of  coding  to  available  listings?  How  can 
this  be  demonstrated? 

b.  Life  cycle  management. 

(1)  Are  any  life  cycle  management  questions  from  Milestone  II  still 
unanswered?  Why? 

(2)  Is  the  computer  resource  life  cycle  management  plan  on  schedule? 
If  not,  what  impact  will  this  have  on  the  entire  weapon  system  during  the 
full  scale  production  phase? 

(3)  When  will  the  software  "turnover"  from  the  contractor  to  the 
Government  take  place?  What  steps  have  to  take  place  before  the  turn¬ 
over? 

(4)  Who  will  provide  software  support  during  operations  and  mainten¬ 
ance?  What  items  will  be  required  in  the  support  base?  How  will  future 
modifications  to  baseline  software  be  handled? 

(5)  What  will  be  the  impact  of  anticipated  software  improvements? 
What  are  the  anticipated  improvements  and  which  areas  of  the  system  will 
be  involved? 
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(6)  What  is  the  general  logic  flow  for  the  system?  How  would  non 
contractor  personnel  go  from  the  general  flow  chart  to  detailed  flow 
charts  to  the  actual  coding?  Is  a  data  item  index  a  deliverable  item? 

(7)  How  is  the  software  compatible  with  operations/logistics 
concepts? 
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ROBERT  L.  MOORE 
Major  General,  USA 
Chief  of  Staff 


DEPARTMENT  OF  THE  NAVY 
HEAOQUARTERS  NAVAL  MATERIAL  COMMAND 

WASHINGTON,  O.C  23360 


From:  Chief  of  Naval  Material 


Ser  UG/iKod 
18  May  198] 


Subj:  Use  of  Standard  Embedded  Computers  in  Navy  Tactical  Digital  Systems 

Ref:  (a)  CNM  ltr  08Y/BWS  Ser  231  of  2  July  1981;  Standard  Embedded 

Computers,  Peripherals,  and  Input/Output  Interfaces  (TADSTAND  B) 
(b)  OPNAVINST  4720. 9D;  Approval  of  Systems  and  Equipments  for  Service 
Use 


1.  Reference  (a)  requires  that  standard  embedded  computers  be  used  in  all 
Navy  tactical  digital  systems,  and  designates  as  Navy  standards  the  AN/UYK-7 
Shipboard  Computer  and  the  AN/UYK-20  Shipboard  Minicomputer.  In  addition, 
reference  (a)  designates  as  planned  standards  the  following  general  purpose, 
embedded  computers: 

a.  AN/AYK-14  Airborne  Minicomputer 

b.  AN/UYK-43  Navy  Embedded  Computer  System  (NECS) 

c.  AN/UYK-44  Militarized  Reconfigurable  Processor  (MRP)  and  Computer  (MRC) 

This  letter  amplifies  policy  for  the  use  of  general  purpose,  standard  embedded 
computers  in  tactical  digital  systems,  as  outlined  in  reference  (a). 

2.  The  AN/AYK-14  has  been  developed  by  the  Naval  Air  Systems  Cormiand  as  a 
standard  airborne  computer  capable  of  satisfying  airborne  embedded  computer 
requirements  through  1990.  The  AN/AYK-14  production  baseline  has  been 
established,  and  first  production  delivery  has  been  accomplished.  The 
AN/AYK-14  is  excluded  from  the  requirement  to  obtain  Approval  for  Service  Use 
under  the  provisions  of  reference  (b)  because  of  impracticality  of  test  and 
evaluation  in  terms  of  planned  mission  capability  until  actually  incorporated 
in  the  using  system,  and  is  now  designated  a  standard. 

3.  The  AN/UYK-43  is  being  developed  by  the  Naval  Sea  Systems  Cormiand  as  a 
family  of  high  reliability,  high  performance  successors  to  the  AN/UYK-7  for 
shore,  surface  ship,  and  submarine  usage.  The  AN/UYK-43  is  specified  to 
execute  AN/UYK-7  software  in  an  upward  compatible  fashion,  and  is  being 
designed  to  execute  computer  programs  up  to  nine  times  faster  than  a  single 
bay  AN/UYK-7  and  have  25  times  increased  memory  capacity.  The  AN/UYK-43  is 
being  developed  with  both  water-cooled  and  air-cooled  enclosures.  The 
AN/UYK-43  is  being  designed  to  reduced  power,  weight,  size,  and  maintenance 
requirements  compared  to  the  AN/UYK-7,  but  with  increased  reliability  and 
availability.  Full  scale  engineering  development  contracts  were  awarded  in 
September  1980.  Delivery  of  AN/UYK-43  Engineering  Development  Models  (EDMs) 
is  scheduled  to  commence  in  March  1983,  and  first  production  delivery  is 
scheduled  for  December  1984. 
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4.  The  AN/UYK-44  is  being  developed  by  the  Naval  Sea  Systems  ,/inand  as 

family  of  high  reliability,  low  cost  processors  and  computers  both  as 
successors  to  the  AN/UYK-20  and  for  direct  embedding  in  equipment.  The 
AN/UYK-44  is  specified  to  execute  AN/UYK-20  and  AN/AYK-14  software  in  an 
upward  compatible  fashion,  and  is  being  designed  to  execute  computer  programs 
up  to  twice  as  fast  as  an  AN/UYK-20  and  have  eight  times  increased  memory 
capacity.  The  AN/UYK-44  is  being  designed  to  reduced  power,  weight,  size,  and 
maintenance  requirements  compared  to  the  AN/UYK-20,  but  with  increased 
reliability  and  availability.  The  AN/UYK-44  is  being  developed  as  a  set  of 
Standard  Electronic  Modules  (SEM)  and  as  a  set  of  components  (e.g.,  integrated 
circuits)  for  direct  embedding  in  equipments  and  systems.  This  form  is  called 
the  Militarized  Reconfigurable  Processor.  In  addition,  the  SEM  card  set  is 
being  packaged  with  memory,  power  supply,  etc.  as  a  complete  Militarized 
Reconfigurable  Computer  (MRC)  with  either  air  or  water  cooling.  Delivery  of 
AN/UYK-44  Advance  Production  Equipments  (APEs)  is  scheduled  to  commence  in 
December  1981  for  MRPs  and  September  1982  for  MRCs.  First  production  delivery 
is  scheduled  for  the  third  quarter  of  1983  for  MRPs  and  the  third  quarter  of 
1984  for  MRCs. 

5.  Accordingly,  the  following  actions  will  be  taken  in  order  to  implement  a 
Naval  Material  Command  policy  of  appropriate  standardization: 

a.  All  shore,  surface  ship,  and  submarine  tactical  digital  systems  that 
will  enter  development  or  undergo  major  upgrade  after  scheduled  availability 
of  AN/UYK-43  EDMs  and/or  AN/UYK-44  APEs  shall  use  the  AN/UYK-43  and/or 
AN/UYK-44,  as  appropriate,  exclusively  as  their  embedded  computers. 

b.  All  tactical  digital  systems  requiring  programmable  processing 
capabilities  directly  embedded  in  equipment  units  that  will  enter  development 
or  undergo  major  upgrade  after  availability  of  AN/UYK-44  MRP  APEs  shall  use 
the  AN/UYK-44  MRP. 

c.  Planning  for  required  use  of  AN/UYK-44  and  AN/UYK-43  shall  begin 
immediately. 

6.  In  order  to  implement  this  policy  as  expeditiously  as  possible.  Commander, 
Naval  Sea  Systems  Command  is  requested  to  initiate  planning  for  orderly 
transition  from  use  of  the  AN/UYK-7  and  AN/UYK-20  to  the  AN/UYK-43  and 
AN/UYK-44  at  the  earliest  feasible  time  throughout  the  Naval  Material  Command. 


Distribution 
(see  page  3) 
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Distribution: 

SNDL  A3  (CNO)  (OP  112,  22,  211,  224,  35,  351,  04,  55,  551,  94,  940,  941, 

942,  944,  95,  98,  982,  983,  only) 

A2A  (CNR) 

A6  (Headquarters,  U.S.  Marine  Corps)  (Codes  LMC-3  and  CCA4  only) 

C4K  (CNM  PMs) 

E3A  (Lab  ONR) 

FE1  (COMNAVSECGRU) 

FF8  (Inspection  and  Survey  Board) 

FF52  (NAVTACINTEROPSUPPACT) 

FG1  (COMNAVTELCOM) 

FKA1A  (COMNAVAIRSYSCOM)  (30  copies) 

FKA1B  (COMNAVELEXSYSCOM)  (30  copies) 

FKA1F  ( COMNAVSUPSYSCOM) 

FKA1G  (COMNAVSEASYSCOM)  (30  copies) 

FKA6A  (CNM  R&D  Centers) 

FKP1G  (NAVSHIPWPNSYSENGSTA) 

FKP14  (FLTCOMBATDIRSSACT) 

FKP15  (INTCOMBATSYSTESFAC) 

FKQ3A  (NAVELEXSYSENGCEN) 

FKQ3B  (NAVELEXSYSENGACTDET) 

FKR3C  (NAVAIRTESTCEN) 

FKR4A  (PACMISTESTCEN) 

FKR5  (NAVAVIONICCEN) 

FLl  COMNAVDAC 
FS1  (COMNAVINTCOM) 

FT1  (CNET) 

FT73  (NAVPGSCHOL)  (Computer  Science,  Engineering,  and  Library  Depts  only) 
26F  (OPTEVFOR) 

V12  (Development  and  Education  Command,  Marine  Corps;  MCTSSA) 

ASN(MRA&L,  RE&S) 

NAVMAT  SP  List  2 

Defense  Systems  Management  College  (Technical  Management  Division) 


Copy  to: 

CNO  (0P-942E3,  0P-982F3) 

DASN(C3I)  (Special  Assistant  for  Computer  Programs) 
Ada  Joint  Program  Office 
U.  S.  Army  (DARCOM-DRCED-C) 

U.  S.  Air  Force  (AFSC-XRF) 


DEPARTMENT  OF  THE  NAVY 

HEADQUARTERS  NAVAL  MATERIAL  COMMAND 

WASHINGTON,  D.C.  20350  p;p;  ,  P!.fa  ,0 

Ser  00/0991 
3  November  1951 


From:  Chief  of  Naval  Material 

Subj:  Standard  Navy  Tactical  Embedded  Computer  Resources  (TECR);  use  of  in 
all  phases  of  system  developments 

Ref:  (a)  CNM  memo  Ser  00/749  of  9  November  1978;  Cost  Control  of  Tactical 

Computer  Software 

(b)  CNM  Itr  Ser  00/855  of  19  December  1978;  Management  of  Computer 
Resources 

(c)  CNM  Itr  Ser  09/0415  of  1  May  1981;  Navy  Ada  Implementation 

(d)  CNM  Itr  Ser  00/0468  of  18  May  1981;  Use  of  Standard  Embedded 
Computers  in  Navy  Tactical  Digital  Systems 

Enel:  (1)  NAVMAT  Policy  Concerning  Tactical  Embedded  Computer  Resources 

1.  The  Chief  of  Naval  Material  (CNM)  in  references  (a)  through  (d) 
promulgated  policy  concerning  the  use  of  Navy  standard  tactical  embedded 
computer  resources  by  activities  of  the  Naval  Material  Command  (NAVMAT). 
Specific  CNM  policies  regarding  the  use  of  embedded  computer  resources  in 
tactical  systems  are  implemented  by  Tactical  Digital  Standards  (TADSTANDs)  and 
NAVMAT  Intructions.  Enclosure  (1)  is  a  current  list  of  these  policy 
documents.  The  purpose  of  this  letter  is  to  reaffirm  the  requirement  for 
NAVMAT  activities  to  comply  with  these  vital  CNM  policies  and  related 
directives. 

2.  In  spite  of  generally  improving  compliance  with  these  CNM  policies  there 
continue  to  be  many  instances  of  system  developments  that  have  effectively 
precluded  the  use  of  Navy  standards  because  of  decisions  and  selections  of 
non-standards  made  in  the  early  phases  of  development.  It  is  thus  essential 
to  reemphasize  the  fact  that  these  policies  apply  to  all  phases  of  tactical 
digital  system  development,  acquisition,  deployment,  and  life  cycle  support. 
The  policies  also  apply  regardless  of  funding  or  acquisition  category. 
Moreover,  TADSTAND  waivers  must  be  obtained  prior  to  commitment  of  funds  to 
use  non-standard  embedded  computer  resources. 

3.  Particular  emphasis  and  attention  must  be  given  to  programmatic  decisions 
that  can  potentially  dictate  the  development  of  tactical  digital  system 
software  using  programming  languages  which  are  not  standard  Navy  higher  order 
languages.  Commitments  to  such  languages,  particularly  hardware-specif ic 
assembly  languages,  usually  make  it  impractical  or  cost  prohibitive  to  later 
convert  software  to  a  Navy  programming  language  for  Navy  standard  computers 
even  though  project  management  had,  in  good  faith,  planned  and  programmed  to 
transition  to  standards.  Recent  experience  has  also  shown  that  assembly 
language  software  developments  that  appear  to  be  insignificant  in  the  early 
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stages  of  system  development  will  usually  expand  to  such  proportions  that  tens 
of  millions  of  dollars  and  often  several  years  of  effort  are  required  for 
subsequent  conversion  of  such  software  to  a  Navy  standard  language. 

4,  The  Tactical  Embedded  Computer  Program  Office  (TECPO)  on  the  CNM  staff 
develops  policy  and  guidance  for  the  use  of  embedded  computer  resources  in 
tactical  digital  systems  by  activities  of  the  Naval  Material  Command.  TECPO 
also  serves  as  the  Principal  Development  Activity  (PDA)  for  Navy  standard 
tactical  embedded  computer  hardware,  programming  languages,  and  related 
support  software.  In  addition,  the  Director  of  TECPO  acts  as  primary  CNM 
advisor  on  the  use  of  embedded  computer  resources  in  tactical  digital 
systems.  Responsible  project/program  managers  are  strongly  urged  to  establish 
liaison  with  TECPO  in  the  early  stages  of  system  development  regarding  their 
digital  hardware  and  support  software  requirements.  In  addition,  such 
managers  who  perceive  the  need  for  changes  and/or  improvements  in  Navy 
standard  TECR  products  or  the  governing  policies  and  directives  are  encouraged 
to  comnunicate  their  concerns  and  recommendations  to  TECPO. 

5.  Systems  Commands,  Project  Offices,  Laboratories,  and  all  other  Naval 
Material  Conmiand  activities  are  to  give  wide  distribution  to  this  letter  and 
related  CNM  policies. 


$  ft 

/J.  G.  WILLIAMS,  ' 

Chief  of  Naval  Material 


Distribution: 
(see  page  3) 
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NAVAL  AIR  SOFTWARE 
MANAGEMENT 
ADVISORY  COMMITTEE 


FOREWORD 


This  Compendium  of  Navy  Software  Management  Policy  and  Guidance 
Documents  has  been  assembled  as  a  result  of  the  Chief  of  Naval  Material 
Letter  on  Management  of  Computer  Resources  (copy  enclosed  at  Section  1). 
The  CNM  letter  underscores  the  requirements  for  NAVMAT  -  wide  com¬ 
pliance  with  all  applicable  NAVMAT  instructions  and  standards  concerning 
tactical  digital  computers  and  software.  Accordingly,  this  document 
contains  a  brief  abstract,  and  a  copy  for  reference,  of  the  principal 
NAVMAT  and  NAVAIR  software  management  instructions,  including  TADSTANDS 
A  through  E  and  TADSTANDS  2,  3  and  9. 

In  an  effort  to  quickly  disseminate  these  software  management 
instructions  to  the  widest  possible  audience  within  the  NAVAIR 
conmunity,  the  Naval  Air  Software  Management  Advisory  Committee  (NASMAC) 
is  making  this  document  available  to  all  cognizant  NAVAIR  technical 
personnel.  Requests  for  this  document  may  be  made  by  contacting  any  of 
the  NASMAC  representatives  listed  at  the  end  of  this  document. 
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CHIEF  OF  NAVAL  MATERIAL  LETTER, 


MANAGEMENT  OF  COMPUTER  RESOURCES  ,  00/855  19  DEC  1978 

ABSTRACT 


•  Emphasizes  requirement  for  all  of  NAVMAT  to  carry  out  CNM  policy  in  matters  concerning 
tactical  digital  computers  and  software. 

•  Directs  attention  to  the  Tactical  Digital  Systems  Office  (TADSO)  on  his  staff,  and  the  role 
of  TADSO  in  development  and  promulgation  of  CNM  computer  and  software  policy. 

•  Cites  nine  TADSTANDS  and  two  NAVMAT  Instructions  as  examples  of  policy  documents 
which  require  compliance  within  NAVMAT  activities 

•  Requests  inputs  on  required  changes  to  applicable  instructions. 


DEPARTMENT  OF  THE  NAVY 

HEADQUARTERS  NAVAL  MATERIAL  COMMAND  Jn£  $er  3 

WASHINGTON  D  C  20360 

00/855 
19  Dec  1 

From:  Chief  of  Naval  Material 

To:  Distribution  List 

Sub j :  Management  of  Computer  Resources 

1.  The  Tactical  Digital  Systems  Office  ( TADSO)  on  my  staff 
develops  tactical  digital  system  policy  and  guidance  for  the 
Naval  Material  Command.  In  addition,  the  Director  of  TADSO 
acts  as  my  primary  advisor  on  tactical  digital  computer  and 
software  matters.  Policy  implementation  usually  takes  the  form 
of  TADSTANDS,  of  which  there  are  now  nine.  TADSTAND  4  defines 
tactical  digital  systems.  The  other  TADSTANDS  specify  actions 
to  be  taken  regarding  computers  and  software,  and  provide  a 
waiver  procedure  to  be  followed  in  those  instances  where 
adherence  to  the  TADSTAND  is  not  practical.  In  other 
instances,  NAVMAT  instructions  are  used  to  implement  software 
management  policy.  For  example,  NAVMATINST  4130. 2A  addresses 
Configuration  Management  of  Computer  Software,  and  NAVMATINST 
5200.27A  establishes  policy  for  the  transfer  of  software 
support  responsibility  to  maintenance  activities  upon 
completion  of  Navy  acceptance.  The  bottom  line  of  these  policy 
directives  is  to  conserve  resources  through  standardization  and 
sound  lire  cycle  management  practices.  The  importance  is 
obvious  in  view  of  the  substantial  resources  being  expended  for 
embedded  computer  resources. 

2.  It  appears  that  some  NMC  acquisition  managers  either  are 
not  familiar  with  these  TADSTANDS  and  directives,  or  ignore 
them.  My  policy  regarding  CNM  directives,  including  the 
TADSTANDS,  is  straightforward.  Necessary  changes  will  be  made 
when  required.  In  the  absence  of  a  clear  rationale  for 
non-compliance,  properly  issued  directives  will  be  followed  by 
Naval  Material  Command  activities.  In  the  case  of 
non-compliance,  the  CNM  will  be  informed. 

3.  I  intend  to  take  whatever  action  is  necessary  to  insure 
that  the  above  policy  is  carried  out,  not  only  in  regard  to 
computer  resources,  but  in  all  NAVMAT  instructions  which 
contribute  to  a  formal,  disciplined  approach  to  the  support  l.  t 
systems  for  which  the  Naval  Material  Command  is  responsible. 
Accordingly,  I  welcome  your  advice  on  any  instructions  that  are 
in  need  of  change. 


Distribution: 
COMNAVAIRSYSCOM 
COMNAVELEXSYSCOM 
COMNAVSEASYSCOM 
PM-1,  2,  3,  4.  S,  22 


CNM  Comment  Sheet  803669 


NAVMATINST  4130.2A 


"CONFIGURATION  MANAGEMENT  OF  COMPUTER  SOFTWARE 
ASSOCIATED  WITH  TACTICAL  DATA  SYSTEMS  AND  OTHER  TECHNICAL 
COMPUTER  SYSTEMS  DEVELOPED  BY  OR  FOR  THE 
NAVAL  MATERIAL  COMMAND" 


ABSTRACT 


•  Provides  policy  and  procedures  for  configuration  management  to  be  applied  to  the 
acquisition  and  maintenance  support  of  software  for  tactical  digital  and  technical 
computer  systems  under  NMC  management. 

•  Directs  that  policy  and  procedures  be  carried  out. 

•  Directs  creation  of  a  Software  Change  Control  Board  (SCCB)  in  most  instances 


Dl  P. 
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DEPARTMENT  of  the  navy 
HEADQUARTERS  NAVAL  MATERIAL  COMMAND 
WASHINGTON  o  C  20360 


NAVMATINST  413C.2A 
MAT- 09Y 

19  July  1976 


TAVMAT  INSTRUCTION  <130. 2A 


Chief  of  Naval  Material 


Subj  :  Configuration  Management  of  Computer  Software  Associated  with 
Tactical  Digital  Systems  and  Other  Technical  Computer  Systems 
developed  by  or  for  the  Naval  Material  Comm, and 

Ref:  (a)  TADSTAND  4  of  6  April  1972 

(b)  NAVMATINST  4130. 1A  of  1  Jul  1974 

(c)  NAVMATINST  5200. 27A  of  18  April  1973 

(d)  0PNAVINST  3500.27B  of  28  June  1974 

(e)  OPNAVINST  4130.1  of  2  Oct  1975 

(f)  SECNAVINST  3560.1  of  8  Aug  1974 

(g)  NAVMATINST  5460. 2A  of  28  July  1975 

1.  Purpose .  To  promulgate  the  responsibilities  of  Naval  Systems  Commanders 
and  Project  Managers  for  configuration  management  of  computer  software  as¬ 
sociated  with  tactical  digital  systems,  and  other  technical  computer  systems 
developed  and/or  maintained  by  the  Naval  Material  Command. 

2.  Cancellation.  This  instruction  supersedes  NAVMAT  Instruction  4130.2  of 
21  September  1970. 

3.  Applicability.  This  instruction  applies  to  Systems  Commanders  and  their 
designated  Project  Managers,  CNM-designated  Project  Managers,  and  CNM  Lab¬ 
oratories/Centers  responsible  for  development,  production,  procurement  and 
maintenance  of  tactical  digital  and  technical  computer  programs  for  ship- 
borne  and  airborne  applications. 

4 .  Definitions 

a.  Tactical  Digital  Systems  are  those  fleet  systems  which  employ 
digital  processing  techniques  and  which  contribute  directly  to  performance 
in  the  areas  of  command  and  control,  navigation,  communications,  weapons 
delivery,  fire  control,  sensor  surveillance,  and  electronic  warfare,  as  de¬ 
fined  by  reference  (a). 

b.  Technical  Computer  Systems  are  those  fleet  systems  which  employ 
digital  processing  techniques,  which  are  related  to  tactical  missions  and 
which  contribute  directly  to  performance  in  the  areas  of  intelligence,  au 
matic  testing .management  informa t ion  and  shipboard  logistic  support. 
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c.  Software  consists  of  the  computer  programs,  computer  data  and  associ¬ 
ated  documentation  related  to  the  operation  of  a  digital  processing  system. 

5 .  Background 

a.  With  the  increased  use  of  tactical  digital  and  technical  computer 
systems  it  has  become  mandatory  that  control  mechanisms  be  developed  and 
used  for  consistent  and  continuing  life-cycle  configuration  management  of  the 
software  in  these  systems.  Software  constitutes  an  entity  equally  as  cri¬ 
tical  as  hardware  and  must  be  described,  documented,  controlled  and  managed 
accordingly.  Configuration  management  must  be  maintained  on  all  digital  sys¬ 
tems  software,  both  during'  development  and  after  it  has  been  delivered  to  the 
Navy  maintenance  activity. 

b  Reference  (b)  states  the  basic  policy,  implementing  guidance  and 
procedures  which  govern  configuration  management  within  the  Department  of  the 
Navy.  Reference  (c)  promulgates  policy  and  procedures  for  the  transfer  of 
tactical  digital  system  software  responsibilities  from  a  development  activity 
to  a  program  maintenance  activity.  Reference  (d)  provides  guidance  for  con¬ 
struction  and  control  of  combat  direction  systems’  digital  processor  pro¬ 
grams  for  the  Navy.  This  guidance  includes  provisions  for  the  monitoring  of 
program  development  by  the  activity  which  will  be  responsible  for  a  program's 
life-cycle  maintenance  and  provides  for  direct  liaison  between  the  Naval  Sys¬ 
tems  Commands  and  the  Fleet  Combat  Direction  Systems  Support  Activities  for 
programs  under  development  by  these  activities.  Inherent  in  the  above  au¬ 
thorities  and  responsibilities  for  monitoring  and  liaison  is  the  requirement 
for  effective  change  control.  Reference  (e)  promulgates  policy  for  con¬ 
figuration  management  of  software  in  surface  ship  combat  systems.  The  prin¬ 
ciples  therein,  excluding  the  detailed  implementation  procedures,  are  applic¬ 
able  to  submarine  and  airborne  systems  as  well.  Reference  (f)  specifies 
documents  required  for  the  implementation  and  maintenance  of  tactical  digital 
computer  systems. 

c.  This  instruction  amplifies  but  does  not  change  the  basic  Systems 
Command  responsibilities  assigned  in  reference  (g) . 

6 .  Policy 

a,  The  policy  and  procedures  for  configuration  management  set  forth 

in  reference  (b)  shall  be  applied  to  the  acquisition  and  maintenance  support 
of  software  for  tactical  digital  and  technical  computer  systems,  subsystems 
and  equipments  under  the  management  of  the  Naval  Material  Command.  Config¬ 
uration  management  of  software  in  surface  ship  combat  systems  shall  also  be 
in  accordance  with  reference  (e) . 

b.  The  procedures  established  by  reference  (c)  and  the  liaison  auth¬ 
orized  by  reference  (d)  shall  be  fully  utilized  in  support  and  implementation 
of  this  policy. 
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7.  Action .  All  components  of  the  Naval  Material  Command  responsible  for 
development,  procurement,  production  and  maintenance  of  computer  software 
associated  with  tactical  digital  systems,  or  technical  computer  systems  shall 
review  their  existing  instructions  and  procedures  and  initiate  necessary 
changes  to  assure  that  the  principles  and  policy  as  set  forth  in  references 
(b)  through  (f)  and  this  instruction  are  applied  to  software  management. 

a.  For  combat  systems  and  other  tactical  digital  and  technical  com¬ 
puter  systems  which  are  under  development: 

(1)  A  Software  Change  Control  Board  (SCCB)  shall  be  established 
as  appropriate  to  review,  evaluate  and  approve/disapprove  proposed  software 
changes.  Proposed  changes,  both  hardware  and  software,  which  impact  the 
approved  software  baseline  technical  documentation  will  be  brought  before  the 
appropriate  Project  Manager/Systems  Command  Software  Change  Control  Board 
(SCCB)  for  resolution  or  will  be  referred  to  the  appropriate  level  in  the 
chain  of  command  within  the  Naval  Material  Command. 

(2)  For  those  systems  under  development  which  require  on-line  ex¬ 
change  of  digital  information  or  data,  an  Interface  Design  Specification 
(IDS)  as  defined  by  reference  (f) ,  shall  be  jointly  developed  and  agreed  to 
by  the  Project  Managers  and/or  the  activities  having  control  of  the  interfac¬ 
ing  systems.  This  document  will  be  the  principal  vehicle  used  to  manage  and 
control  the  software  interface  configuration  of  the  ship  combat  system  or 
other  systems. 

b.  For  combat  systems,  interfacing  software  systems,  and  other  applic¬ 
able  subsystems  which  are  passing  from  control  of  the  acquiring  project  man¬ 
ager  to  the  maintenance  manager,  or  for  those  systems  which  are  already  under 
control  of  the  maintenance  manager,  the  following  conditions  apply: 

(1)  The  maintenance  manager  will  either  continue  the  project 
manager's  SCCB,  or  if  none  exists,  create  a  SCCB  as  described  in  subparagraph 
7.a(l)  above,  utilizing  the  appropriate  technical  documentation  as  defined 

in  reference  (f ) . 

(2)  Membership  of  the  SCCB  will  be  expanded  to  include  representa¬ 
tion  from  each  interfacing  software  subsystem  life-cycle  maintenance  activ¬ 
ity. 

(3)  For  those  systems  which  require  on-line  exchange  of  digital 
data,  the  IDS  will  continue  to  be  the  principal  document  for  software  inter¬ 
face  configuration  control. 
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c.  Reference  (e)  specifies  additional  guidance  required  in  the  case 

of  surface  ship  combat  systems  regarding  chairmanship  of  the  SCCB.  For  ether 
tactical  digital  and  technical  computer  programs,  the  project  manager/main¬ 
tenance  manager  shall  specify  the  chairmanship  of  the  SCCB. 

d.  For  platforms  and/or  command  centers  which  communicate  via  data  links 
and/or  other  off-line  media  (e.g.,  magnetic  tape,  disk  packs,  punched  cards), 
an  inter-platform  IDS  shall  be  jointly  developed  and  shall  be  the  principal 
document  for  interface  configuration  control.  A  Software  Change  Control 
Board  shall  be  established  for  the  joint  control  of  this  interface.  If  the 
interfacing  systems  are  the  total  responsibility  of  one  command ,: the  SCCB 
shall  be  established  at  that  level.  If  the  interfacing  systems  dre  the 
responsibility  of  more  than  one  Systems  Command,  the  SCCB  will  be  established 
by  CNM .  Representatives  of  the  individual  platform  SCCBs  shall  be  members 

of  the  joint  SCCB. 

8.  Implementation.  For  software  systems  under  development,  the  provisions 
of  this  instruction  are  to  be  implemented  irwiediately .  For  those  operational 
ships  and  aircraft  being  delivered  with  Model  IV,  Phase  0  NTDS  or  ATDS  Pro¬ 
grams,  implementation  shall  be  no  later  than  concurrent  with  the  delivery,  of 
these  programs.  For  already  operational  software  systems,  the  provisions  of 
this  instruction  are  to  be  implemented  no  later  than  1  January  1977.  For 
those  systems  that  already  have  a  Change  Control  Board  (CCB)  or  its  equiva¬ 
lent  in  existence,  where  the  function  of  the  existing  CCB  is  to  review  soft¬ 
ware  changes  as  well  as  hardware  changes,  and  provided  there  are  software 
knowledgeable  personnel  representing  the  members  of  that  CCB,  a  separate 
SCCB  need  not  be  established . 
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NAVMATINST  5200.27A 


"TRANSFER  OF  NAVY  TACTICAL  DIGITAL  SYSTEM  SOFTWARE 
RESPONSIBILITY;  PROCEDURES  FOR" 

ABSTRACT 


•  Provides  procedures  for  the  transfer  of  Navy  tactical  digital  system  software  responsibility 

•  Directs  that  procedures  be  followed. 
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NAVMAT  INSTPUCTION  5200. 27 A 


1R  Anr  1 Q 7 3 


Free:  Chief  of  Naval  Material 


Sue j :  Transfer  of  Navy  Tactical  Digital  System  software 
responsibility;  procedures  for 


re: 


(a)  NAVMAT  Instruction  5230.5  of  11  Aug  1971 

(b)  TA_D STAND  1(  of  6  Apr  1972  (NOTAL) 


Enel : 


(1)  Operating  Procedures 

(2)  Format  of  Program  Maintenance  Milestone  Chart 


1.  Purpose .  To  promulgate  policy  and  procedures  for  the  transfer  of 
Navy  Tactical  Digital  System  software  responsibility  from  a  develop¬ 
mental  activity  to  a  program  maintenance  activity. 

2.  Cancellation.  NAVMATINST  5200.27  is  cancelled. 

3.  Background .  It  is  realistic  to  assume  that  utilization  of  general 
purpose,  programmable,  digital  processors  will  continue  and  will  grow 
in  importance.  Presently,  tactical  digital  systems  processor  programs 
constitute  the  principal  medium  through  which  refinements,  improvements, 
and  new  applications  in  fleet  combat  systems  are  introduced  into  the 
fleet.  The  production  of  such  programs  and  associated  documentation  is 
an  undertaking  comparable  in  cost  and  complexity  to  the  design  and 
development  of  the  system  equipments.  In  recognition  of  these  factors. 
Navy  digital  processor  programming  activities  were  established  to  design, 
develop,  produce  and  maintain  operational  programs  for  tactical  digital 
systems  (TDS).  It  was  originally  expected  that  the  activities  would 
provide  the  initial  as  well  as  the  follow-on  digital  processor  program¬ 
ming  support  for  TDS.  However,  because  of  the  rapidly  groving  number 

of  TDS  designs  and  the  increasing  maintenance  requirements  for  existing 
TDS  programs,  it  has  become  necessary  for  the  systems  developing  activ¬ 
ity  to  provide  digital  processor  programming  support  for  many  develop¬ 
mental  TDS  and/or  integral  subsystems  through  a  prime  contractor.  This 
support  is  then  subsequently  assigned  to  a  Navy  programming  activity 
for  the  duration  of  the  operational  life  of  the  system.  Under  these 
conditions  it  becomes  necessary  for  each  activity  concerned  with  the 
development  of  new  systems  or  functional  application  to  address  ir.  both 
an  efficient  and  timely  fashion  the  problem  of  transferring  responsibil¬ 
ity  anc  providing  adequate  computer  programming  support  of  delivered 
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.  Definitions 

a.  Digital  processor  programming  or  software  as  used  in  this 
instruction  consists  of  programs  resident  in  digital  processors  or 
other  storage  devices.  Examples  of  these  include,  but  are  not  limited 
to;  assemblers,  compilers,  simulators,  emulators,  utility,  diagnostic 
and  maintenance  programs  and  the  documentation  necessary  to  generate 
and  support  the  above  digital  processor. 

b.  Tactical  digital  systems  are  defined  in  reference  (b). 

5.  Policy .  Uninterrupted  software  support  of  tactical  digital  systems 
being  introduced  into  the  fleet  is  essential  for  successful  deployment. 
Efficient  management  of  the  transition  of  digital  processor  programm¬ 
ing  responsibility  from  the  development  phase  to  the  operational  phase 
will  assure  the  necessary  support.  This  responsibility  will  be  carried 
out  within  a  standard  discipline  and  framework  consistent  with  the 
guidance  of  higher  authority  and  in  consonance  with  the  procedures  out¬ 
lined  herein. 

6.  Responsibility .  The  basic  responsibility  for  policy  guidance,  co¬ 
ordination,  and  assistance  throughout  the  Naval  Material  Command  for 
all  tactical  digital  systems  is  assigned  to  the  Director,  Tactical 
Digital  Systems  Office  (TADSO , MAT- 09Y )  by  reference  (a). 

T.  Applicability.  This  instruction  is  applicable  to  the  Deputy  Chiefs 
of  Naval  Material,  the  Naval  Systems  Commanders,  the  Director  of  Labora¬ 
tory  Programs  and  CNM-Designated  Project  Managers. 

8 .  Action . 

a.  Addressees  shall  be  guided  and  governed  by  the  procedures 
set  for-h  in  enclosures  (l)  and  (2). 

b.  A  copy  of  all  project  planning  documents  concerning  digital 
processor  program  maintenance  shall  be  fowarded  to  TADSO  (MAT  09Y). 

c.  Approval  for  the  designation  of  program  maintenance  activities 
must  be  obtained  from  TADSO  (MAT  09Y). 

tffa.i - 
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OPERATING  PROCEDURES 

The  following  procedures  will  be  adhered  to  in  the  transfer  ol 
digital  processor  programming  responsibility  for  Tactical  Digital 
Systems  from  a  development  activity  to  a  program  maintenance  activity. 

1.  Principal  Development  Activity  (PDA),  shall  determine  the  follow¬ 
ing  during  the  initial  planning  phase: 

a.  Which  project  planning  documents  will  contain  the  Digital 
Processor  programming  maintenance  requirement.  If  an  Integrated 
Logi^'.ic  Support  Plan  (ILSP)  is  to  be  prepared  for  the  proposed  pro¬ 
ject,  the  ILSP  shall  be  used  as  the  means  of  delineating  these  re- 
qui  -rents.  If  no  ILSP  is  required  for  the  project,  then  a  Software 
Lift.  Cycle  Management  Plan  shall  be  generated  and  shall  specify,  in 
detail,  the  Digital  Processor  programming  maintenance  requirements. 

b.  In  the  event  that  a  "Project  Office"  is  not  established,  an 
appropriate  agent  shall  be  designated  for  implementing  the  require¬ 
ments  specified  herein. 

c.  Identify  the  Navy  activity  and/or  contractor  responsible  for 
providing  Digital  Processor  programming  maintenance.  Concurrence  will 
be  obtained  from  the  activity  that  support  cam  be  provided  as  required 
by  the  project. 

2.  The  project  planning  document  shall  contain,  as  a  minimum,  the 
following  items: 

a.  A  chronological  (time-sequence)  chart  which  defines  milestones 
for  events  related  to  the  orderly  transfer  of  software  responsibility 
to  the  maintenance  activity.  Enclosure  (2)  is  to  be  used  as  a  guide 

in  the  preparation  of  the  milestone  chart.  Events  which  clarify  the 
overall  turnover  procedure  for  each  project  should  be  detailed.  The 
format  for  the  chart  is  left  to  the  discretion  of  the  preparing  acti¬ 
vity  except  that  the  chart  shall  denote  the  milestones  as  related  to 
both  calendar  and  fiscal  year  chronology. 

b.  A  listing  of  estimated  equipment,  personnel,  facility  require¬ 
ments,  and  necessary  liaison  required  by  the  Digital  Processor  programm¬ 
ing  maintenance  activity. 

c.  Funding  requirements  for  accomplishing  paragraph  2.b. 

d.  A  statement  of  impact,  and  any  required  action  because  of 
paragraph  2.b  and  2.c,  on  other  Systems  Commanders  to  support  (interface) 
with  the  program  maintenance  activity. 


ENCLOSURE  (1) 


HAVKATINST  5200. 27 A 

18  Apr  1973 

e.  Documentation  requirements 

f.  Life  cycle  funding  support  for  system  software  being  developed. 

g.  Procedures  for  the  submission  of  Digital  Processor  program 
change  requests. 

h.  Define  use  of  high  level  language  in  accordance  with  TADSTAND  1. 

i.  When  applicable,  specify  concurrence  with  the  guidelines  for 
construction  and  control  of  tactical  digital  systems  computer  programs 
as  detailed  in  OPNAV  Instruction  03500. 2A.  Delineate  any  deviations  re¬ 
quired  because  of  unique  circumstances  not  covered  in  the  instruction. 

3.  The  designated  programming  maintenance  activity  shall  be  made  a 
participant  in  the  project  during  the  development  phase.  This  partici¬ 
pation  shall  include  as  applicable,  but  not  be  limited  to,  the  following: 

a.  The  establishment  of  a  liaison  team.  NOTE:  Unless  the  urgency 
of  the  operational  requirement  for  the  system  dictates  a  shorter  time 
frame,  the  liaison  team  should  operate  for  a  period  of  at  least  12 
months  prior  to  the  turnover  date. 

b.  Definition  of  liaison  procedures  and  requirements. 

c.  Review  of  Digital  Processor  program  design  specifications. 

d.  Monitoring  Digital  Processor  programming  efforts. 

e.  Provide  programming  technique  guidelines,  such  as  for  modular 
programming . 

f.  Provide  existing  operational  program  modules  for  use  where 
appropriate. 

g.  Provide  advice  and  consultation  on  operational  doctrine. 

h.  Definition  and  review  of  the  Navy  test  plan  for  acceptance  of 
the  contractual  effort  (i.e.  system,  engineering  changes,  etc.). 

i.  Prepare  in  conjunction  with  the  PDA  a  maintenance  programming 
production  plan.  This  plan  shell  specify  the  sequential  programming 
test  and  integration  events  associated  with  the  production  of.  the  soft¬ 
ware.  The  plan  shall  also  specify  the  interrelationship  of  the  mainten¬ 
ance  activity  with  the  cognizant  PDA  when  operational  requirements  dictate 
changes  which  affec+  the  operational  hardware  and/or  system  performance. 
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j.  Review  Engineering  Change  Proposals,  and  comment  on  their 
effect  on  Digital  Processor  programs. 

k.  Review  and  advise  the  program  manager  of  computer  programming 
changes . 

4.  If  weapon  system  trainers  and  simulators  are  to  employ  (as  an 
integral,  part  of  the  design)  general  purpose  processors,  the  PDA  shall 
perform  reviews  prior  to  any  contractual  commitment  to  determine  what 
impact  there  is  on  the  operational  software  procedures  presented  herein. 
Specifically,  documentation,  languages,  and  when  applicable,  machine  type 
should  be  minimized  as  to  the  differences  with  the  requirements  of  this 
Instruction. 

5.  It  is  the  specific  responsibility  of  each  PDA  to  insure  that  both 
the  intent  as  well  as  the  requirements  presented  herein  are  not  cir¬ 
cumvented  because  of  the  establishment  of  terms  and  conditions  of  a 
contract  with  an  industrial  firm.  Each  PDA,  as  appropriate,  implement 
the  following  to  effect  compatibility  of  this  instruction  with  the 
proposed  effort: 

a.  In  the  request  for  proposals  (RFP)  there  shall  be  listed  a 
line  item  for  the  requirement  on  the  part  of  the  contractor  to  interface 
with  the  proposed  maintenance  activity  as  detailed  herein.  All  costs 
for  any  tiavel,  data,  etc.,  shall  be  clearly  specified.  The  role  of 
the  maintenance  activities  as  a  Navy  team  member  and  technical  monitor 
shall  be  so  stated  in  the  contract. 

b.  Establish  in  the  contract  review  points  such  that  new  doctrine, 
procedures,  or  new  and  unforeseen  tactical  situations  are  examined  for 
impact  on  the  baseline  digital  processor  programs.  These  reviews  should 
be  consistent  with  the  system  equipment  and  software  design  "freeze" 
points.  It  is  recognized  that  in  certain  instances,  the  incorporation 
of  new  capabilities  could  impact  the  performance  guarantees,  schedules, 
and  cost  of  a  given  project.  In  such  cases,  the  PDA  is  to  present  to 

the  Chief  of  Naval  Material  and  the  Chief  of  Naval  Operations,  for  review, 
a  concise  explanation  of  the  effect  on  the  project  if  such  requirements 
are  added  and  any  proposed  alternatives.  Additionally,  the  PDA  is  to 
establish  reviews  in  a  time  frame  that  will  permit  adequate  review  prior 
to  the  design  "freeze"  for  the  baseline  system. 

c.  In  those  cases  where  the  contractor  develops  the  initial  programs 
for  developmental  systems  and  these  programs  are  subsequently  used  as 
"interim"  operational  programs,  the  Systems  Command  shall  provide  for 
contractual  coverage  of  improvements  and  new  capabilities. 
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From:  Commander,  Naval  Air  Systems  Command 

To:  *  Deputy  Commander,  Assistant  Commanders,  Comptroller,  Cormnand 
Special  Assistants,  Designated  Project  Managers,  Project 
Coordinators,  and  Office  and  Division  Directors 

Sub j :  Responsibility  and  requirements  for  preparation  of  Software 
life  Cycle  Management  Plans  (SLCM?) 

Ref:  (a)  NAVAIRINST  5230.4  of  1  Aug  1974,  Responsioi 1 i ty  for  the 

coordination  and  management  of  weapon  system  tactical  digital 
processors  and  related  software 
(b)  NAVMATIN'ST  5200. 27A  of  18  Apr  1973,  Transfer  of  Navy 

Tactical  Digital  System  software  responsibility,  procedures  for 

Enel:  (1)  Requirements  for  a  Software  Life  Cycle  Management  Plan  (SLCMP) 

1.  Purpose.  This  instruction  establishes  the  requirements  and  the 
responsibility  for  the  preparation  and  implementation  of  Software  Life 
Cycle  Management  Plans  (SLCMP)  for  weapon  system  tactical  digital  pro¬ 
cessors  and  related  software. 

2.  Background.  Reference  (a)  designated  the  Director  of  the  Avionics 
Division  ^AIR-533)  as  the  manager  of  all  weapon  system  tactical  digital 
processors  and  related  software.  Software  management  plans  of  varying 
degrees  of  detail  and  in  numerous  formats  have  been  developed  for  certain 
weapon  systems.  AIR-533  has  determined  that  to  successfully  manage 
weapon  systems  tactical  software,  it  is  necessary  to  develop  a  SLCMP  for 
each  weapon  system.  In  accordance  with  reference  (a),  Project  Managers 
(PMs)  and  Acquisition  Managers  (AMs)  arc  responsible  for  providing  to 
AIR-533  sufficient  funding  to  allow  AIR-533  to  obtain  software  support 
activity  (SNA)  and  contractor  services  required  in  the  preparation  and 
update  of  a  SLCMP.  Reference  (b)  establishes  the  requirement  for  a  plan 
to  transfer  responsibility  for  software  management  from  the  development 
activity  to  a  SSA.  The  requirements  of  reference  (b)  are  encompassed 
within  enclosure  (1). 

3.  Scope.  The  SLCM?  will  address  the  operational  software  requirements 
for  the  complete  life  cycle  of  the  weapon  system.  It  shall  be  originated 
prior  to  the  issuance  of  the  Request  for  Proposal  (RFP)  for  full  scale 
development  and  shall  be  kept  current  thereafter  throughout  the  life 
cycle  of  the  system.  The  •  SLCMP  will  address  the  operational  software, 
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support  system  software  and  their  possible  interfaces  with  automatic 
test  cquif"""cr.  ’nr!  trainers.  It  will  identify  the  disciplines,  resources, 
and  procedures  necessary  for  proper  control  of  the  weapon  system  software 
from  conception  throur.h  ultimate  fleet  utilization  of  the  system.  It  is 
mandatory  that  pertinent  requirements  generated  by  cho  SLOW  tie  included 
in  the  RFP.  Prior  to  final  determination  of  chc  cost  for  a  project  all 
known  and  probable  software  life  cycle  costs  shall  be  identified  in  the 
SLCMP .  Upon  approval  by  the  PM  or  Aft  the  SLCMP  shall  become  che  governing 
document  for  operational  software  life  cycle  support. 

4.  Appllcabi liev.  The  requirements  of  this  instruction  apply  to  all 
tactical  digital  processor  software  for  weapon  systems  which  arc  the 
responsibility  of  the  Naval  Air  Sysccms  Command  Headquarters  (NAVAIR  HQ) 
and  Naval  Air  Systems  Command  (NAVAIR)  funded  and  tasked  activities. 

The  requirements  of  this  instruction  shall  not  be  cause  for  reformatting 
existing  software  management  plans.  The  content  of  existing  plans 
however,  shall  be  reviewed  for  consistency  with  che  concent  requirements 
of  enclosure  (1)  and  shall  be  updated  as  required  to  incorporate  the 
requirements  of  this  instruction.  This  instruction  does  not  provide  for 
ground  suppore  equipment  processors,  training  equipment  processors  or 
related  software,  which  are  provided  for  separately. 

5.  Responsiblity 

a.  The  Director  of  the  Avionics  Division  (AIR-533)  is  responsible 
for  the  preparation  and  update  of  SLCMPs  in  accordance  wich  this  in¬ 
struction. 

b.  Each  PM  or  AM  shall  have  approval  authority  of  the  SLCMP  for  his 
project . 

c.  The  Assistant  Commander  for  Test  and  Evaluation  (AIR-06)  shall 
review  all  SLCMP  submissions  to  ensure  thac  the  proper  tese  and  evaluaiion 
(TSE)  is  planned  for  and  Chat  the  resources  and  facilities  required  are 
planned  to  support  approved  requirements. 

6.  Ac C Ion.  PMa  and  AMs  shall,  on  a  continuing  basis,  revir-w  their  software 
management ' planning  for  adequacy  and  compliance  wich  chic  instruction. 

7.  Forms.  DD  Form  1423,  Concract  Data  Requirements  List  is  stocked  in 
the  NAVAIR  KQ  Foma  Stock  Room. 
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REQUIREMENTS  FOR  A 
SOFTL.Vr.  r  L I  F  z  ^LE  *  O'.  N  AC  EM  ENT  PLAN 

(SLCMP) 


1 . 0  INTRODUCTION 

1.1  PURPOSE 

The  Software  Life  Cycle  Management  Plan  (SLCMP)  will  define  those  tasks, 
procedures,  and  functions  to  be  performed  throughout  the  life  cycle  of  the 
associated  weapon  system  and  will  identify  the  responsibilities  and  scope  of 
participation  of  all  activities  (Na vy /Con t r ac tor )  in  Software  Life  Cycle 
Kanagcmen  c . 

1.2  OBJECTIVES 

The  objectives  of  the  SLCMP  will  be  to  provide  for  Navy  control  of  weapon 
system  software;  to  provide  for  an  orderly  transition  of  software  support  re¬ 
sponsibilities  from  the  development  contractor  or  Navy  developer  to  the  Soft¬ 
ware  Support  Activity  (SSA);  and  to  provide  effective  design,  development,  and 
support  of  ueapon  system  related  software  tnroughout  its  life  cycle. 

Upon  acceptance  of  the  SLCMP  by  the  appropriate  Project  Manager,  the  policy 
stated  will  be  applicable  to  all  aspects  of  the  ueapon  system  which  uses,  impacts, 
or  is  inpacted  by  the  associated  software  system. 

1.3  SCOPE 

The  SLCM?  will  address  the  tactical  software  requirements  for  the  complete 
life  cycle  of  the  weapon  system.  It  shall  be  originated  prior  to  the  issuance 
of  the  Request  for  Proposal  (RFP)  and  shall  be  kept  current  thereafter  through¬ 
out  the  life  cycle  of  the  system. 

The  SLCMP  will  address  the  operational  and  support  system  software  and 
their  possible  interfaces  with  automatic  test  ecuipment  and  trainers.  It  will 
identify  the  disciplines,  tesources,  and  procedures  necessary  for  proper  control 
of  weapon  system  software  from  conception  through  ultimate  fleet  utilization  of 
the  system.  It  is  imperative  that  pertinent  requirements  generated  by  the  SLCMP 
be  included  in  the  RFP. 

1.4  ORGANIZATION  OF  THE  PLAN 

The  material  presented  in  the  SLCMP  will  be  arranged  in  two  volumes.  Volume 
I  shall  contain  eight  sections:  (1)  Introduction,  (2)  Standards,  Specifications 

•nd  Instructions,  (3)  Software  S'Ttcms  Description,  (4)  Software  Life  Cvcle 
Plans  and  Milestones,  (Si  Software  Management  Organization,  (6)  Software  Config¬ 
uration  Management,  (7)  Quality  Assurance,  and  (S)  Software  Documentation. 
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Appendices  Co  Volume  1  of  the  SLCMP  will  include  Acronyns,  Definitions, 
Key  Personnel,  and  Software  System  Technical  Descriptions. 

Volume  II  of  the  SLCMP  shall  have  United  distribution  due  to  the 
proprietary  nacure  of  the  material  and  shall  concain  sections  covering  Task 
Descriptions,  Resource  Requirements  and  Funding,  Software  Responsibility 
Transition,  and  Inter-Activity  Working  Agreements,  as  appropriate  co  the 
project. 

1.4.1  Volume  I  -  Sections 


The  Software  life  cycle  management  policies,  procedures,  and  respon¬ 
sibilities  applicable  co  the  weapon  system  will  be  described  in  Sections  1.0 
through  8.0.  The  policies,  procedures,  and  requirements  set  forth  in  these 
sections  will  provide  for  Navy  control  of  weapon  system  software  and  for  an 
orderly  transition  of  software  support  responsibilities  from  the  development 
contractor  or  Navy  developer  co  Che  Software  Support  Activity  (SSA). 

1.4. 1.1  Section  1.0:  INTRODUCTION  -  This  section  will  provide  an  introduction 
to  the  SLCMP.  The  organization  of  the  SLCMP  will  be  summarized  co  provide  an 
overview  of  che  concencs;  procedures  for  maintenance  of  the  SLCMP  will  be 
identified.  This  section  will  also  state  che  purpose,  scope,  and  objectives 

of  the  SLCfP,  and  will  discuss  Che  history  and  background  of  che  software 
aspects  of  the  weapon  system  project. 

1.4. 1.2  Section  2.0:  STANDARDS.  SPECIFICATIONS .  ACT  INSTRUCTIONS  -  This 
section  will  identify  the  standards,  specifications,  and  instructions  governing 
software  management.  Compliance  with  .VAVAIR,  iVAVMAT,  0?.\V\V,  and  DoD  instructions 
and  standards  will  be  required. 

1.4. 1.3  Section  3.0:  SOFTWARE  SYSTEMS  DESCRIPTION  -  This  section  will  identify, 
define,  and  describe  the  weapon  system  operational  software  system  and  it's 
interface  with  automatic  test  equipment,  trainer,  and  support  system  software. 

1.4. 1.4  Seccion  4.0:  SOFTWARE  LITE  CYCLE  PLAN'S  AND  MILESTONES  -  This  section 
will  describe  che  three  major  phases  of  the  sottwa*e  life  cycle:  (1)  The 
Software  Development  Phase,  which  includes  pre-develooment/design  and  develop¬ 
ment  tests  and  evaluation;  (2)  the  Transition  Phase,  during  which  all  software 
support  is  transferred  from  the  development  contractor  to  the  Navy  (SSA)  ;  and 
(3)  the  Navy  Support  Phase,  during  which  the  Navy  assumes  full  responsibility 
for  total  software  support. 

Schedules  and  milestones  of  major  events  associated  with  the  develop¬ 
ment,  acquisition,  and  management  of  software  throughout  che  software  life  cycle 
will  be  depicted.  Special  emphasis  shall  be  directed  toward  che  schedules  of 
events  involved  in  early  Introduction  of  Navy  SSA  personnel  in  the  development 
phase  and  in  transferring  software  management  responsibility  from  che  contractor/ 
Navy  developer  to  the  Navy  SSA. 
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1.4. 1.5  Section  3.0:  SOFTWARE  MANAC  F>!  FN'T  PRO  \N  I  7.AT  t  ON  -  This  section  will 
identify  tlic  various  soft-art  support  activities  and  orf.initatu.u.,  »..uJ  define 
their  responsibilities  end  their  supporting  rela t i onsli ips  with  and  between 
each  other  throughout  the  software  life  cycle. 

1 ;  4 . 1 . 6  Section  f» ,  0  :  SOrT'.'tRr  CONFIGURATION  HA  NAGD-iPN'T  -  This  section  will 
encompass  the  requirements  of  software  configuration  management,  configuration 
identification,  configuration  change  control,  and  change  status  accounting  as 
they  apply  to  the  weapon  system  related  software. 

1.4.1. 7  Section  7.0:  QUALITY  ASSURANCE  -  This  section  will  describe  the 
quality  assurance  procedures  to  be  applied  and  uill  encompass  development/ 
modification,  verif ication/validation  and  certification,  test  and  evaluation 
and  production. 

1.4. 1.8  Section  8.0:  SOFTh'AP-E  DOCUMENTATION  -  This  section  uill  describe  the 
Software  Documentation  applicable  to  the  project.  It  will  identify  SF.CNAVINST 

3560.1  as  the  governing  specification,  describe  the  documentation,  detail  the 
documentation  delivery  schedule,  describe  contractor  monitoring,  contract 
specifications.  Government  prepared  documentation,  and  supportive  technical 
documentation  requirements.  On-going  projects  documented  in  accordance  with 
previous  standards  will  describe  the  system  documentation  in  accordance  with 
those  standards. 

1.4. 1.9  Appendices 

1.4. 1.9.1  Appendix  A:  Acron-ms  -  This  appendix  will  contain  those  project 
peculiar  acronyms  needed  to  be  conversant  with  the  project,  as  well  as  those 
acronyms  commonly  used  in  software  engineering  and  management  terminology. 

1.4. 1.9. 2  Appendix  B:  Definitions  -  This  appendix  will  contain  a  standardized 
set  of  software  and  project  oriented  definitions. 

1.4. 1.9. 3  Appendix  C:  Key  Personnel  -  This  appendix  will  contain  a  list  of 
key  personnel  associated  with  the  project,  including  codes,  phone  numbers, 
and  addresses. 

1.4. 1.9.4  Appendix  D:  Software  System  Technical  Description  -  This  appendix, 
will  be  utilized  on  an  optional  basis  to  provide  more  detailed  technical 
descriptions  of  the  software  systems  and  subsystems,  to  supplement  Section 
3.0  of  the  SLCMP. 

1.4. 1.9. 5  Optional  Appendices  -  The  addition  of  other  optional  appendices  is 
left  to  the  discretion  o:  the  SSA. 
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1.4.2  Volume  II  -  Section* 

1.4. 2.1  Section  1:  TASK  DESCRIPTIONS  -  This  section  will  include  task 
descriptions  based  upon  authorised  ALRTASRS  and  Work.  Units. 

1.4. 2. 2  Section  2:  RESOURCE  REQUIREMENTS  AND  FUN-piNC  -  This  section  will 
include  funding  estimates  for  ail  activities  participating  in  the  software 
life  cycle  management.  Included  will  be  both  short-range  and  long-range 
budget  estimates/requirements.  Resource  requirements  such  as  Facilities, 
Equipment,  Manpower,  and  Support  will  also  be  identified.  A  definitive 
statement  on  the  contents  of  this  section  is  included  as  Attachment  A  to 
this  SLOtP  Requirements  Document. 

1.4. 2. 3  Section  3:  SOFTWARE  RESPONSIBILITY  TRANSITION  -  This  section  will 
consist  of  the  SSA's  transition  plan  for  assuming  responsibility  from  the 
contractor  or  Mavy  developer  for  ultimate  Navy  support  of  the  software  system 
and  will  include  a  milestone  chart  of  major  evencs  associated  with  the  tran¬ 
sition. 


1.4. 2. 4  Section  4:  INTER- ACTIVITY  WORKING  ACREPIENTS  -  This  section  will 
include  those  negotiated  inter-activity  working  agreements  which  have  been 
developed  and  agreed  upon. 

1.4.2. 5  Cptlonal  Sections  -  Any  additional  information  which  the  SSA  finds 
of  value  in  managing  the  weapon  system  nay  be  included  as  an  optional  section. 


1.4.3 


Changes  to  the  Plan 


Changes  to  the  basic  SLCMP  will  be  mode  according  to  schedules 
established  in  the  basic  document.  The  basic  document  shall  describe  the 
processes  for  updating,  and  changing  the  SLCiP. 
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2 . 0  STANDARDS  .  SPECIFICATION,  AND  INSTRUCTION’S 

Applicable  standards,  specifications,  and  instructions  will  be  adhered  :c 
and  will  be  referenced  in  the  SLCMP.  The  following  standards,  specif  ;c«tior.s  , 
and  instructions  of  the  issue  in  effect  on  the  date  of  invitation  for  bid  or 
RJP  address  the  core  elements  comprising  tiie  specific  requirements  to  be 
included  in  the  SLCMP.  Additional  recognized  standards  may  be  included  as 
appropriate.  Care  must  be  taken  in  utilizing  standards  and  specifications  not 
under  C lie  direct  control  of  the  Navy.  Instructions  may  be  used  in  preparing 
the  SLCMP  but  should  be  avoided  as  references  in  contract  requirements. 

2.1  STANDARDS 

MIL-STD-480  Configuration  Control  -  Engineering  Changes, 

Deviations  and  Waivers 

MIL-STD-481  Configuration  Control  -  Engineering  Changes 

(Short  Form) 

MIL-STD-482  Configuration  Status  Accounting  Data  Elements 

and  Related  Features 

M1L-STD-483  Configuration  Management  Practices  for  Systems, 

Equipment,  Munitions,  and  Computer  Programs 

MIL-STD-490  Specification  Practices 

Mll-STD-630  Contractor  Standardization  Plans  and  Management 

MIl-STD-882  System  Safety  Program  for  Systems  and  Associated 

Subsystems  and  Equipment,  Requirements  for 

MIL-STD- 1 521  Technical  Reviews  and  Audits  for  Systems,  Fquipmert, 

and  Computer  Programs 

2 . 2  SPECIFICATIONS 

MIL-Q-985R  Quality  Program  Requirements 

HIL-S-S3490  Specifications,  Types  and  Forms 

US-8506  Requirements  for  Digital  Computer  Program 

Documentation  (Superseded  by  SECNAVIN'ST  3590.1) 

2.3  INSTRUCTIONS 

SECNAVINST  3560.1  Tactical  Digital  Systems  Documentation  Standards 

SECNAVINST  5233. LA  Department  of  the  Navy  Automatic  Data  Systems 

Documentation  Standards 

OPNAVINST  3500. 27E  Construction  and  Control  of  Digital  Processor 

Programs  for  the  Navy  Combat  Direction  System 
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OPNAVINST  4790.2A  Naval  Aviation  Maintenance  Program 

NAVMATINST  3960.6  Planning  and  ]  mp  1  cr.ienta  t  ion  of  Tests  and 

Evaluations  of  New  Weapon  Systems 

NAVMATINST  4130. 1A  Department  ot  Defense  Configuration  Manual 

NAVMATINST  4130.2  Configuration  Management  nr.d  Change  Control 

Procedures  for  Taccical  and  Technical  Computer 
Programs 

NAVMATINST  4130. 3A  Standard  Combac  System  Automatic  Data  Processin 

Hardware  and  Software:  Joint  Configuration 
Management  of 

NAVMATINST  52^0. 27a  Transfer  of  Navy  Tactical  Digital.  System  Soft¬ 

ware  Responsibi lity;  Procedures  for 

NAVAIRINST  3960.2  Tesc  and  Evaluation  Master  Plans;  Policies  and 

Procedures  Concerning  the  Preparation,  Processi 
and  Approval 

NAVAIRINST  4130.1  NAVAIRSYSC0M  Configuration  Management  Manual 

NAVAIRINST  4200.14a  Policy  and  Guidelines  for  Procurement  of  Data 

and  Specific  Acquisition  of  Unlimited  Rights 
in  Technical  Data 

NAVAIRINST  4275. 3B  Configuration  Control,  MIL- STD-480  and 

MIL-STD-481A ;  implementation  of 

NAVAIRINST  5215. 8A  The  NAVAIR  Technical  Directives  System 

NAVAIRINST  5230. 3A  Scandard  Specification  for  Weapon  Systems  Digit 

Processor  Programming  Documentation 

NAVAIRINST  5230.4  Responsibility  for  the  Coordination  and  Manage¬ 

ment  of  Weapon  System  Tactical  Digital  Processo 
and  Relaced  Software 

NAVAIRINST  5400.14a  Policies  and  Procedures  for  the  Transfer  of 

Engineering  Cognizance  of  and  Production  Suppor 
Responsibilities  for  Service  Equipment  to  -Navy 
Field  Activities 

2.4  LOCAL  COMMAND  INSTRUCTIONS 

Applicable  local  command  instructions,  if  required  for  clarification,  wi 
be  appended  co  the  SLCMP. 
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The  software  systems  dcsrr<ptl''(i  includes  the  major  software  systems, 
subsystems,  the  relationship  between  chc  software  components  of  the  svsirm . 
types  of  software,  support  software,  and  the  technical  documentation  for  ail 
of  the  above.  As  ..ppropr ia te ,  it  will  also  address  system  interfaces  with 
automatic  ccst  equipment  and  trainers. 

3.1  CENERAL 

This  section  will  contain  a  brief  overview  of  the  total  project  software 
system. 

3.2  OPERATIONAL 


The  functions  performed  by  the  operational  software  will  be  delineated  in 
a  narrative  description  in  this  section,  as  an  overview  of  the  Program  Perfor¬ 
mance  Specification  requirements.  Operational  software  includes  both  tactical 
and  on-board  system  test  software  and  its  supporting  documentation. 

3.2.1  Tactical  Software 

The  functions  performed  by  the  tactical  software  will  be  delineated  in 
this  section.  Tactical  software  is  that  software  executed  in  the  weapon  system 
computer(s)  which  provides  those  functions  required  for  the  performance  of  the 
tactical  missions  of  the  weapon  system. 

3.2.2  On-Board  System  Test  Software 

The  functions  performed  by  on-board  system  test  software  will  be 
delineated  in  this  section.  On-board  system  test  software  includes  programs 
designed  co  provide  readiness  test,  fault  isolation,  performance  non i t or i nc. , 
maintenance  data  retrieval,  and  special  test  capability  integral  to  the 
weapon  system. 

(1 )  Readiness  Test  Programs  provide  fault  detection  capability  for 
the  avionics  and  avionics  controlled  portions  of  the  weapon  system  by  means  of 
an  end-to-end  and  individual  component  tests.  These  programs  are  generally 
operator  initiated  and  are  used  for  pre/post  flight  testing  and  for  verifica¬ 
tion  of  maintenance  repair. 

(2)  Fault  Isolation  Programs  provide  diagnostic  capability  to  the 
Weapons  Replaceable  Assembly  (WRA)  or  lower  component  level  in  the  weapon  system. 


(3)  Per formjr.ee  Monitor  Programs  automatically  monitor  weapon  system 
performance  and  alert  operators  and/or  the  tactical  program  of  malfunction,  to 
allow  selection  of  degraded  node  operation. 


(A)  Maintenance  Data  Retrieval  Programs  allow  automatic  collection 
of  pertinent  in-flight  system  performance  information  that  is  utilized  for 
post-flight  analysis  of  system  malfunctions,  failures,  and  degraded  performance. 
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(5)  Spec  ini  Test  Pro^rnms  provide  maintenance  tests  that  arc  not 
part  of  normal,  readiness  test  or  fault  isolation  routines.  Examples  are 
weapon  release  tests,  system  alignment  routines,  computer  lood/vcrlfy  pro¬ 
grams,  and  data  link  evaluation  programs.  These  programs  are  usually  noc 
time-constrained  as  arc  most  system  readiness  tests. 

3.3  AUTOMATIC  TEST  EQUIPMENT  (ATE)  SOFTWARE 

The  functional  interfaces  of  the  operational  program  with  the  ATE  uill 
be  delineated  in  this  section.  ATE  software  includes  programs  for  weapon 
syscera  peculiar  and  common  ground  support  equipment  (CSE)  that  is  utilized 
for  test  and  diagnosis  of  the  weapon  or  its  components. 

3. A  TRAINER  SOFTWARE 

The  functional  interfaces  of  the  operational  program  with  the  trainers 
involved  in  the  project  will  be  detailed  in  this  section  and  will  define  the 
inter-relationships  uic!  operational  software  programs. 

3.5  SUPPORT  SOFTWARE 

Support  software  will  be  defined  and  described  in  this  section.  Support 
system  software  includes  compilers,  assemblers,  utility  packages,  diagnostic 
routines,  integration  test  programs,  simulation,  and  other  software  associated 
with  the  general  support  function. 

3.6  INTERFACE  CONFIGURATION 

The  hardware  interface  comf iguracion  baselines  will  be  defined  and  described 
In  this  section.  Hardware  interface  includes  compucer-co-compucer  and  computer- 
to-periphcral  equipment  interfaces. 
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4.0  SOHh'APC  LIPK  CVCIT  PLANS  ANT)  KH.riTONFS 

This  section  will  identify  major  elements  of  the  r.of tv.-.re  life  cycle  which 
cost  be  addressed  ir.  software  life  cycle  pi nr.n in;; .  The  weapon  system  software 
life  cycle  r.ay  be  divided  into  three  ph.-sen:  V: .ana  I  -  Software  Devil-..-. 

Pbanc;  Phase  II  -  Software  Transition  Phase;  and  Phase  Ill  -  b'avy  Software 
Support  Phase-.  These  three  phases  may  overlap,  since  all  software  elements  or 
subsystems  of  a  weapon  system  nay  not  complete  each  phase  simultaneously. 

The  plans,  milestones,  and  schedules  to  provide  life  cycle  manage- er.t  of 
weapon  system  software  will  be  identified  in  detail  in  th:s  section  of  the 
SLCMP .  Tnis  section  will  provide  guidance  in  planning  the  acquisition  ant- 
support  of  sof twarc/computer  resources,  including  equipment  and  program...  This 
guidance  will  apply  to  cases  in  which  these  resources  are  separately  identifiable 
at  the  outset  and  to  cases  in  which  they  arc  identified  during  the  course  of  a 
system,  subsystem,  or  equipment  development  process. 

The  individual  software  life  cycle  events  and  requirements  will  be  iden¬ 
tified  and  defined  in  the  order  of  programmed  occurrence.  This  section  will 
reflect  the  time(s)  required  for  these  events  to  materialize  and  progress  from 
Start  to  completion,  and  will  present  all  of  the  events  together  to  portray  the 
major  elements  of  the  total  weapon  system  software  life  cycle  in  a  tine-phased 
sequence.  In  addition,  this  section  will  plan  and  schedule  acquisition,  devel¬ 
opment,  and/or  allocation  of  resources  needed  for  future  development  and  growth 
of  the  weapon  system  software. 

In  identifying  and  stating  the  needs  for  new  or  improved  weapon  systems 
capabilities,  it  is  essential  to  consider  the  impact  of  software  and  computer 
resources  on  weapon  system  operation  and  its  r.ninta:  nab i It ty  and  support.  Tne 
required  capability  must  consider  the  life  cycle  mission,  intended  interlace, 
and  relationship  with  existing  cr  planned  systems.  -When  initiating  software 
and/or  computer  ic-source  requirements,  either  separately  or  as  a  part  of  .- 
weapon  system,  the  using,  supporting,  and  other  part i c ipat , np,  activities 
requirements  will  be  identified  and  alternative  solutions  (if  any)  will  be 
provided . 

4.1  riVE  YLAK  PLAN 

The  events  programmed  to  occur  during  the  first  five  years  of  the  software- 
lift.  cycle  vi 11  be  presented,  reflecting  the  relationship  between  elements. 

This  portion  of  the  SLCMP  will  provide  the  Project  Manager  with  the  necessary 
visibility  into  the  software  life  cycle  requirements  and  milestone  corplclion 
dates  during  che  programmed  five  year  period. 

During  the  conceptual  phase,  analyses  ar.d  tradeoff  studies  must  be  per¬ 
formed  to  establish  feasibility  and  assess  risks  relative  to  software  and 
computer  resources  development  and  supportabi 1 i ty .  These  studies  will  be 
conducted  by  the  implementing  organization  with  inputs  from  all  of  the  pur.i- 
cipating  activities.  S t arida rd i ;a t ton  considerations  for  software,  computer 
hardware,  programming,  and  programming  language  shall  be  considered  in  these 
studies  and  tradeoffs. 
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The  five  year  plan  will  Include  a  time-phased  schedule  detailing  chc 
management  nilcstoues.  Direction  and  assi  gr.nctiC  o£  responsibiliti  es  will 
emphasize  planning  and  acquisition  nnnugunenc  attention-  to  software  and 
computer  resources  including  computer  programs  to  be  used  in  new  weapon 
systems . 

Management  milestones  such  as  Che  Defense  Systems  Acquisition  Review 
Council  (DSAXC) ,  formal  test  and  evaluation  (TLE),  and  initial  operational 
capability  (IOC)  which  will  relate  software  development  with  weapon  system 
development  will  be  included  as  appropriate.  The  Program  Management  Directive 
(PMD)  will  provide  guidance  and  direction  in  establishing  many  of  the  major 
program  milestones  and  will  assign  responsibilities  to  the  appropriate 
accivities/organiza cions . 

4.2  PHASE  I  -  DEVELOPMENT  PHASE 

Phase  1,  the  Development  Phase,  will  involve  (1)  ehe  determination  and 
definition  of  weapon  system  software  rtquirer._r.es  based  on  Navy  weapon  system 
planning  documents,  (2)  contraccor/Navy  development  of  software  specifications 
for  all  elements  of  the  weapon  system  software,  and  (3)  programming,  integra¬ 
tion,  and  checkout  of  inicial  software  definitions. 


4.2.1  Pre-Development 

The  pre-development  portion  of  Phase  I  of  the  software  life  cycle  includes 
Che  definition  of  Navy  requirements,  Chc  statement  and  definition  of  the 
resources  required,  and  the  proposal  and  contract  writing. 

4.2.1. 1  KKP  Preparation  -  This  section  will  Include  all  software  life  cycle 
requirements  to  be  delineated  in  the  RFP  which  will  be  che  responsibility  of 
the  software  contractor  or  Navy  developer. 

4. 2. 1.2  Conrracc  '-’ricing  ~  The  software  specifications  and  contract  software 
deliverable  items  chat  arc  to  be  included  in  chc  concract  shall  be  idenc i „ icd - 
Only  NAVA I R  HQ  approved  Daca  Item  Descriptions  (DIDs)  will  be  specified  on 

DD  Form  1423,  Concracr  Data  Requirements  List  (CD.'.L).  These  DIDs  will  incor¬ 
porate  the  rcquiremer.es  of  SLCNAVtNST  3560.1  and  unjnuc  NAVA  I R  HQ  requirements. 


4.2.2 


Design  and  Development 


During  Phase  I  che  weapon  system  software  will  be  designed,  developed, 
coded,  debugged,  integrated,  and  tested  in  both  laboratory  and  flight  envi¬ 
ronments  . 


4. 2. 2.1  System  Analysis  -  Systems  analysis  will  address  the  definition  of 
requirements  and  the  identification  of  constraints.  It  will  also  address  che 
weapon  system  vehicle,  the  weapon  system  operational  environment,  and  the  real 
time  response  requirements.  The  weapon  system  software  requirements  will  be 
identified  from  Navy  planning  documents 
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4. 2. 2. 2  Concept  For:-.  In :  ion  -  Concept  forru’.'.tion  si. ell  describe  the  method  (s  ) 
for  ir.pl  c:  cnt.it  i  or.  o :  the  f.  o  t  iw.’i  r  (  functions  cvulv.-ig  i  rue  sveterr.  nr.alvs  in 
will  describe  how  func:  ;or.s  .'.re  to  be  allocated  to  c:.  I  l  log  ere  ,  nr- 

cqn  ipr.'nt  ,  soft’-. ire,  an  i  per  * onnvl .  The  ter. :  re  ;  t  n  r  or  !.;w  dcvelc;  ■.  r  u-ill 
establish  a  clcr-ir/i  approach  for  all  c- lemur:  to  of  the  weapon  system  so  t  t  --a  r  c . 

4.2.2.  3  rerfcrrar.ee  and  Design  D  nee  i  f  i  c  a  t  i  car.  -  Weapon  oyster-,  performance 
specifications  and  software  design  specifications  will  be  written  by  the  con¬ 
tractor  or  Navy  developer  in  response  to  i equirementr.  identified  in  haw  plan-, 
ning  documents,  requests  for  quutat ion/proposal ,  and  contracts. 

4. 2. 2.  3.1  Prcl  ir.-.ir.arv  Design  Review  (PPP.)  -  The  purpose  of  a  TDK  is  to  eval¬ 
uate  the  progress,  consistency,  and  technical  adequacy  of  a  selected  design  ar.d 
test  approach;  and  to  establish  compatibility  with  program  requirements  anc 
preliminary  design.  A  PDR  r.ay  be  used  first  to  approve  the  Program  Performance 
Specif  icatior,  (ITS),  followed  by  review  of  the  preliminary  design  to  ensure 
compliance  with  the  approved  requirements.  PDRs  shall  be  conducted  for  each 
computer  software  Configuration  Item  (Cl)  identified  as  part  of  the  weapon 
system. 

4.2.2.  3.2  Pr  ior  it  izat  ion /Assessment  -  As  a  result  of  PDRs,.  areas  of  software- 
requiring  additional  development  will  be  prioritized  and  assessed.  Priori¬ 
tization  will  address  the  necessity  for  meeting  the  specification  requirements 
and  operational  requirements.  Assessment  will  reflect  the  funding  limitations 
in  light  of  the  prioritization. 

4. 2. 2. 3. 3  Critical  Design  Review  (CDR )  -  A  CD?,  shall  be  conducted  for  each  Cl 
prior  to  start  of  computer  program  coding  and  testing.  This  review  will  cor. pa: i 
the  Tccom.r.er.ded  design  with  the  detailed  requirements  of  the  dcvtl  cpr.-en:  speci¬ 
fication.  The  rcccir:  ended  design  will  normally  he  documented  by  a  finalized  PiT. 
and  a  preliminary  Program.  Description  Document  (PCD)  for  each  Cl.  1?  a  Data 
Ease  Design  (DiiD)  document  has  been  developed,  it  shall  also  be  reviewed  . 
Following  the  CDR,  computer  program  designs  will  be  released  foi  coding  and 
testing,  resulting  in  finalization  of  the  PDD  for  each  Cl.  This  donum  r.tal  ior. 
constitutes  the  Cl  product  baseline. 

For  both  1 1  ■  c  PDR  and  CDR,  the  Navy  review  team  shall  corn.pr i .sc  a  repre¬ 
sentative  cross-section,  of  involved  Navy  Activities  to  ensure  comp  i  ebons  i  ve- 
evaluation  of  all  pertinent  areas  and  disciplines. 

4. 2. 2. 4  Cod  inp/  bah  Tes  t  s  /  Cor...  i  1  a  t  ion  -  The  process  of  implementing  soft¬ 
ware  design  (coding,  compiling,  and  testing)  shall  be  in  accordance  with  the 
contract  and  approved  related  documents  and  data.  Developmental  milestones 
shall  be  established  with  appropriate  testing  to  verify  achievement  of  each 
goal.  Minimum  requirements  for  a  recompile  shall  be  defined  to  insure  that 
programs  do  not  accumulate  excessive  errata  during  development.  Data  will  be 
recorded  and  analyzed  during  tests  (both  ground  and  flight)  in  a  pilot  pro¬ 
duction  aircraft.  This  will  aide  in  determining  the  degree  to  which  the 
Software  satisfies  its  allocated  requirements  as  part  of  the  complete  weapon 
system,  a,.d  will  facilitate  the  localization  of  deficiencies  for  elimination 
or  correction  prior  to  the  test  and  evaluation  phase. 
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4. 2. 2. 5  IK-vi- 1  oprrut  Monicor  -  Navy  software  support  activity  and  tcsc  and 
evaluation  r*-prc  .client  ivcw  will  nonitor  the  Gontrjetoi  development  cycle  and 
w  1  incus  contractor  testing  Jnd  development  miU--.cniu.-u  to  provide  Navy  visi¬ 
bility  into  jol  tv.ire  development.  Cons idf ra t i on  should  tv  given  to  the 
require. -not  for  tin-  Navy  SNA  to  establish  a  software  simulation  facility  lor 
the  purpose  of  conducting  verification  and  validation  testing.  This  coordi¬ 
nated  activity  will  permit  insight  into  possible  trouble  areas.  Knowledge  of 
current  status  of  all  software  development  will  be  provided,  an  veil  as  early 
visibility  of  the  contractor's  ability  to  meet  design  goals.  Design  reviews 
will  be  held  at  milestone  goals  during  the  contractor  development  cycle. 

4. 2. 2. 6  Design  Changes  -  Design  changes  to  Che  software  and  the  documenta¬ 
tion  of  those  changes  will  be  the  responsibility  of  c!ie  contractor  oi  Navy 
developer  in  pursuing  the  initial  development ,  cest,  and  evaluation  of  die 
system .  The  SSA  will  monicor  the  design  change  process  in  order  to  acquire  an 
in-depth  knowledge  of  Che  software  configuration.  The  SSA  will  also  monitor 
the  configuration  management  requirements  of  the  contract  to  ensure  that  Che 
contractor  or  Navy  developer  is  correctly  applying  configuration  identifica¬ 
tion,  control,  and  status  accounting.  All  changes  shall  be  fully  documented. 
The  NAVAlR-dirccccd  software  design  management  team  shall  review  and  approve 
all  design  changes  chat  affect  program  performance. 

4.2.2. 7  Integrnc ion  -  This  is  Che  process  of  bringing  together  the  system 
software  and  hardware  in  a  laboratory  and/or  actual  cest  vehicle.  Integration 
testing  will  be  performed  in  accordance  wich  previously  approved  test  plane 
and  procedures.  Due  to  Che  large  amount  of  supporting  hardware  and  software: 
usually  required,  detailed  facility  and  test  planning  is  essential. 

4.3  PHASE  II  -  TRANSITION  PHASE 

Phase  II,  Che  Transition  Phase,  begins  toward  the  end  of  Phase  I,  con¬ 
tinues  through  cest  and  evaluation  and  ends  shortly  alter  initiation  of  the 
Navy  support  phase.  Phase  II  includes  formal  acceptance  Tf.E,  validation  oi 
documentation,  SSA  assumption  of  custody,  configuration  accounting  responsi¬ 
bility,  FlctC  introduction  coordination,  and  preparation  for  future  r.c>ftwarc 
support . 

4.3.1  Configuration  Nonage. none 

During  Phase  II,  the  software  may  undergo  frequent  change  arid 
development  to  correct  deficiencies  chat  become  apparent  during  test  and 
evaluation  efforts.  Configuration  management  of  software  changes  is  mandatory 
during  this  phase.  Navy  conf iguration  identification  and  status  accounting 
will  begin  at'  chc  start  of  this  phase.  The  milestones  and  procedures  for  Navy 
assumption  of  configuration  control  responsibility  will  be  identified  in  chc 
SLOIP  and/or  the  Configuration  Management  Plan.  Decails  of  the  configuration 
management  process  will  be  described  in  Seccion  6.0. 
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4.3.2  Tost  and  EvoIu.it  ion  (TIE) 

Test  and  Evaluation  *"11  include  laboratory  and  flight  testing.  .-,m! 
evaluation  of  tin-  software  through  contractor  •demonstration  tests  and  a  fci:  ii 
Navy  evaluation  program.  TiF.  covers  the  entire  spectrum  of  test  and  ev. ] na¬ 
tion  for  systems,  subsystems,  equipment,  and  software.  The  purpose  of  tin: 
total  test  effort  is  to  verify  The  performance  and  compliance  v:ith  specifi¬ 
cations  of  conf igur at  ion  items,  subsystems,  and  the  total  integrated  system 
and  associated  software. 

Both  die  technical  and  operational  pe-rf orcancc  of  the  software  will 
be  tested  during  this  phase.  All  data  and  documentation  vv.ll  be  closclv 
monitored  by  the  Navy  test  and  evaluation  and  SSA  representatives  during  this 
period  to  ensure  they  are  updated  and  reflect  the  current  configuration. 

Formal  Navy  evaluation  programs  which  stay  include  Navy  Preliminary 
Evaluations  ( NV E ) ,  Navy  Technical  Evaluations  (NIC) ,  Initial  Operational  Tost 
and  Evaluations  (IOTiE),  and  Board  of  Inspection  and  Survey  (CIS)  will  be 
conducted  by  designated  Navy  test  and  evaluation  agencies  during  this  period. 

Prior  to  commencement  of  any  formal  Navy  evaluation,  a  program  tape, 
certified  as  ready  for  evaluation,  shall  be  provided  to  the  K.wy  by  the  con¬ 
tractor  or  Navy  developer.  Operational  Test  and  Evaluation  (OT&F.)  nay  be 
conducted  during  or  after  the  Development  Test  &  Evaluation  (DTtE)  period. 

4.3.3  Fleet  Introduction 

During  the  latter  portion  of  Phase  II  a  limited  number  of  weapon 
systems  will  be  introduced  into  Fleet  training  squadrons.  Phase  III  of  the 
software  life  cycle  will  begin  with  this  introduction  and  continue  during  the 
remainder  of  the  weapon  system  life  cycle.  The  SSA  will  coordinate  Fleer 
introduction  of  the  software  system. 

4.4  PHASE  III  -  NAVY  SUPPORT  PHASE 

Phase  III,  the  Navy  Support  Phase,  will  begin  v/ith  the  SSA's  assumption 
of  responsibilities  for  the  weapon  system  software,  and  will  continue  du.ing 
the  remainder  of  the  weapon  system  life  cycle. 

4.4.1  Software  Changes 

Software  changes  may  be  initiated  in  response  to  problems  discovered 
during  user  operations,  or  to  meet  new  requirements.  Problems  or  new  require¬ 
ments  will  be-  sufficiently  defined  to  permit  development  of  solutions. 

4.4.2  Configuration  Management 

In  Phase  III  total  configuration  management  is  the  responsibility  of 
the  Navy.  The  Navy  will  ensure  coordination  of  all  weapon  system  software- 
changes  with  their  associated  Fleet  requirements,  as  well  as  complete  config¬ 
uration  control  of  all  weapon  system  software.  Fleet  participation  in  the 
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Software  Change  Review  Board  (SCRB)  Is  mandatory  during  this  phase.  Official 
Navy  Software  Baseline  configuration  will  have  bern  established  and  ciianp.es  to 
all  system  software  arc  subject  to  MIL-iTD-430  control.-  Detailed  configura¬ 
tion  management  procedures  will  be  developed  and  included  in  Section  G.O. 

4.4.3  Evalunt  ion/Assessmsne 


The  Impact  of  proposed  chnngc(s)  upon  the  total  weapon  system  and 
weapon  system  operational  capability  will  be  evaluated  and  assessed. 

4.4.4  Change  Implementation 

Following  approval,  the  change  (s)  will  be  implemented.  The  SSA  will 
be  responsible  for  change  design  and  implementation. 

4.4.5  Test  and  Evaluation  (T&E) /Approval 

All  changes  will  be  tested  and  evaluated  (validated,  verified,  and 
approved)  by  an  organization  independent  of  the  change  developer.  Test  and 
evaluation  requirements  will  be  determined  by  the  Software  Change  Review 
Board.  NAVAIR  HQ  will  designate  or  request  the  responsible  TtE  activity  to 
perform  this  function.  Test  and  Evaluation  of  programs  incorporating  changes 
will  include  appropriate  testing  of  the  entire  program  to  ensure  that  the 
changes  have  not  adversely  affected  ocher  program  areas. 

4.4.5  Distribution 

Following  acceptance  by  the  test  and  evaluation  activity  the  SSA 
will  reproduce  and  distribute  Che  final  version  of  the  software  in  accordance 
with  the  distribution  instructions  contained  in  the  SLCMP. 

The  software  change  block  implementation  schedule  and  schedule  for 
Fleet  introduction  will  be  determined  by  the  Software  Change  Review  Board. 

4.5  SUPPORT  SYSTEM  ACQUISITION 

The  cocal  software  life  cycle  suppoit  system  acquisition  requirements 
shall  be  portrayed  in  a  decarled  schedule.  The  PHD  normally  will  contain 
detailed  requirements,  schedules,  and  the  accivities/organizacions  responsible 
for  the  above. 

Identification  of  funding  and  effective  long  range  planning  and  adequace 
lead  eime  for  the  procurement  of  support  systems  is  mandatory. 

4.6  FACILITIES 

The  tocal  life  cycle  facilities  requirements  will  be  portrayed  in  a 
detailed  schedule.  This  schedule  will  be  updated  periodically  as  new  infor¬ 
mation  becomes  available.  Detailed  descriptions  of  specific  facilities  will 
be  contained  in  Volume  II,  Section  2:  Resource  Requirements  and  Funding. 
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The  software  management  organization  is  the  functional  cler.ua:  i.hli 
provides  management  for  the  weapon  system  software  throughout  the  )  j  f  o  cycle. 
This  organization  operates  within  established  NAVAIR  HQ  policies  and  proce¬ 
dures  governing  change  control  during  all  phases  of  the  Weapon  System  Software 
Life  Cycle. 

The  Software  Management  Organization  provides  the  necessary  management 
effort  (i.e.,  planning,  administration,  and  direction  for  all'  software  devel¬ 
opment,  utilization,  verification  and  validation,  and  configuration  manage¬ 
ment)  throughout  the  software  life  cycle,  and  will  administer  and  maintain 
configuration  management  and  control  procedures  and  disciplines  in  accordance 
with  MIL-STD-480 ,  MIL-STD-481  and  NAVAIRINST  4130.1. 

5.1  INVOLVED  ORGANIZATIONS 


Organizations  involved  in  software  management  will  include  NAVAIR  HQ,  the 
SSA,  participating  Navy  activities.  Fleet  users,  and  various  contractors. 
Sections  5.1.1  through  5.1.5  of  the  SLCMP  will  identify  the  cognizant  codes  of 
the  respective  organizations  and  define  their  responsibilities  for  software 
life  cycle  management  during  the  three  phases.  The  internal  structure  of  each 
organization  showing  lines  of  authority  and  responsibility  shall  be  shown. 


5.1.1 


NAVAIR  HC 


5.1.2  Field  Acitivitles/Labs 


5.1.3  Contractors 


5.1.4  Other  Navv  Activities 


5.1.5  SSA  Internal  Operations 


5.2  ORGANIZATIONAL  RESPONSIBILITIES 


Functional  charts  and  organizational  diagrams  shall  be  constructed  to 
show  the  composition  and  interrelationship  between  activities  compri:..  ■>  the 
Software  Management  Organization. 

5.2.1  Liaison 

Close  liaison  among  all  activities  in  the  software  management 
organization  must  be  maintained  during  the  life  cycle  of  the  weapon  system. 
Pirect  liaison  responsibilities  shall  be  clearly  defined  by  the  SLCMP. 


5.2.2 


Authority 


The  activities  comprising  the  software  management  organization 
■hall  operate  within  their  assigned  authority.  The  SLCMP  will  define  each 
activity's  authority  and  responsibility,  as  outlined  in  NAVAIR  HQ  and  other 
Command  directives. 
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5.2.3  Bo arris /Conn  Lee ccs 

Boards  and/or  committees  may  Be  formed  to  provide  assistance  to 
management  for  the  life  cycle  of  the  weapon  system  software.  Representatives 
of  :!  'Se  boa : ds /comnit tees  shall  be  identified  In  the  SLCMP  by  activities,  and 
the  responsibilities  of  each  shall  be  defined  in  detail  in  the  SLC'Q’. 

5. 2. 3.1  Software  Chance  Review  Board  (SCRB)  -  The  SCRB  shall  be  established 
and  be  responsible  for  weapon  system  software  life  cycle  change  management . 

The  Project  Manager  will  designate  the  chairman  of  the  SCRJ1.  The  SCRB  shall 
comprise  tactical  and  Syscem  Test  Program  (STP)  subcommittees,  as  applicable, 
containing  a  representative  cross  section  of  all  involved  activities.  Func¬ 
tions  of  the  SCRB  will  be  defined  in  Section  6.4.3. 

5. 2. 3. 2  Other  3oa rd s /Commi t tees  -  Additional  boards  and/or  comnittces  shall 
be  designated  when  and  if  the  need  arises. 

5.3  REPORTINC  REQU IRD1ENTS 

The  progress  of  all  activities  involved  in  support  of  the  weapon  system 
software  life  cycle  will  be  detailed  through  the  publication  of  reports*as 
scheduled  in  the  SLCMP. 


5.3.1 


AIRTASK  Requirements 


The  identification  of  items  co  be  reported  on  as  well  as  the  required 
schedule  of  these  reports  will  be  included  in  AIRTASHS.  The  information 
addressed  in  reports  by  specific  individual  activities  in  response  to  AIRTASKS 
will  be  identified  in  the  SLCCP  to  prevent  duplication  and  permit  dissemination 
of  the  total  information  available,  concerning  the  weapon  system  software. 


5.3.2 


Special  Requirements 


Any  special  category  report  initiated  by  local  Commands  or  Staffs 
Vi1!  e  included  in  the  SLCMP  if  the  information  contained  therein  will  assist 
other  activities  involved  in  the  weapon  system  software  life  cycle. 


5.3.3  Report  Distribution 

The  distribution  of  all  reports  shall  be  listed  in  the  SLCMP. 
Standard  distribution  lists  may  be  included  in  Appendix  C. 
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Compr  clicns  1  vc  software  coni  ifi.r.uion  man.ip.cmcnt  Is  an  integral  part  of 
the  total  software  management  for  the  weapons  system. 

This  section  will  provide  the  plan  by  which  software  configuration  :  ■. mage- 
men  t  practices  and  procedures  are  applied  consistently  and  uni^o rtr.lv  t h :  ou ,  .out 
the  life  cycle  of  the  weapon  sysccm.  Specifically,  these  are  considered  c.-.rJy 
in  the  acquisition  cycle.  It  will  provide  additional  information  that  is  unique 
to  software  and  computer  programs  and  provide  guidance  in  ihe  application  c: 
configuration  management  principle.-',  to  sof tware/conputer  program  acquisition, 
operation,  and  support.  It  will  apply  to  configuration  identification,  control, 
and  status  accounting,  in  accordance  with  the  guidance  and  principles  expressed 
in  MI  L- STit- 480 ,  MIL- STD-481  and  NAVAIRINST  4130.1.  Configuration  nanacenient 
data  requirements  si. all  be  included  on  the  DD  form  1423,  CDRE. 

6.1  DEFINITION 

Configuration  Management  is  a  discipline  applying  technical  and  adminis¬ 
trative  direction  and  surveillance  to  (a)  identify  and  document  the  functional 
and  physical  characteristics  of  a  configuration  item,  (b)  control  changes  to 
those  characteristics,  and  (c)  record  and  report  change  processing  and  imple¬ 
mentation  status.  Configuration  management  is  thus  the  means  through  which 
the  integrity  and  continuity  of  the  design,  engineering,  and  cost  trade-off 
decisions  which  are  made  between  technical  performance,  produc t ib il i t y  ,  opera¬ 
bility,  and  supportability ,  are  recorded,  communicated,  and  controlled  by 
program  and  functional  managers. 

The  SLCMP  will  provide  the  general  procedures  and  processes  for  software 
configuration  management  of  Che  system.  This  section  may  be  expanded  into  a 
subsidiary  document,  the  Software  Configuration  Management  Plan.  This  plan 
will  outline  those  requirements  and  procedures  which  will  be  required  to 
effect  conrrol  of  nil  software  configuration  related  to  the  weapon  system. 

The  Softuarc  Conf i gurat ion  Management  Plan  will  reflect  the  requirements  and 
procedures  needed  for  effective  and  timely  configuration  control  of  weapon 
system  software. 

6.1.1  Fac  tors 

The  primary  factors  of  configuration  management  arc  the  overall 
control  of  the  system,  the  specific  identification  of  various  configurations, 
the  effective  control  of  changes  to  those  configurations,  and  the  interface 
with  other  systems. 

Software  configuration  management  requirements  must  be  addressed  in 
the  RFP.  The  RFP  must  contain  sufficient  information  to  ensure  that  respondees 
may  adequately  address  both  developmental  software  configuration  management 
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and  transition  of  conf iguracicn  management  to  Navy  control.  In  tills  respect, 
the  SLOtP  shall  contain  a  coni igura t ion  man.-igcmenc  concept  chat  extends  through¬ 
out  the  entire  life  cycle  of  the  weapon  systen  and  considers  relationships  ol 
the  developing,  supporting,  and  using  Commands.  The  Softwaie  Configuration 
Management  Plan  will  develop  this  concept  in  further  detail. 

6.1.2  Organizations  Involved 

The  organization  for  software  configuration  management  will  consist 
of  Che  NAVAIR  HQ  and  the  Software  Change  Review  Board  (SCRil).  The  Sofeware 
Support  Activity  (SSA)  will  function  as  implementor  of  configuration  changes 
approved  by  NAVAIR  HQ  and  the  SCRB. 

The  key  role  of  NAVAIR  HQ  will  be  chat  of  Project  Manager.  The 
specific  NAVAIR  HQ  codes  will  be  identified  in  the  organization  breakdown. 

The  key  roles  of  the  Software  Change  Review  Board  will  be  to  establish 
detail  procedures  relative  to  the  configuration  control  process  to  be  used  by 
all  participants,  to  review  and  recommend  disposition  of  all  proposed  software 
changes,  and  to  recommend  the  testing  required  to  validate 'and  certify  so/tvare 
programs . 


The  key  role  of  the  SSA  will  be  that  of  maintaining  configuration 
identification,  accounting,  and  change  implementation. 

6.2  CONFIGURATION  IDENTIFICATION 

Configuration  identification  is  the  current  approved  or  conditionally 
approved  technical  documentation  for  a  configuration  item  ns  sec  forth  in 
specifications,  drawings  and  associated  lists,  flow  charts,  and  (  ocuraencs 
referenced  therein. 

Each  item  of  computer  software  will  be  allocated  specific  performance 
requirements  from  the  overall  system  performance  requirements,  chrough  the 
system  engineering  process.  These  requirements  will  be  documented  in  a 
Program  Performance  Specification  (PPS).  The  prograiuj  shall  be  designed  to 
meet  the  PPSs  and  shall  be  tested  to  ensure  that  the  design  achieves  specified 
performance  objectives. 

The  physical  design  of  each  software  item  will  be  documented  as  a  Config¬ 
uration  Item  in  accordance  with  MIL-STD-480,  MIL-STD-481,  MIL-S-83490,  and 
SECNAVINST  3560.1.  Each  configuration  item  will  be  identified.  Strict  config¬ 
uration  identification  will  be  maintained  on  each  sofeware  configuration  item. 
Configuration  identification  requirements  must  be  included  on  the  CDRL. 

6.2.1  Responsibi-icy 

The  performance  requirements  will  be  as  specified  in  Navy  planning 
documents.  The  prime  contractor  or  Navy  developer  will  maintain  configuration 
identification  for  the  weapon  syscem  while  Chi  software  is  contractor-furnished 
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equipment.  The  Navy  (SSA)  will  assume  responsibility  for  software  lor  fig¬ 
uration  ident 1 f if at  ion  and  rci dent  1 f lent  ion  at  the  end  of  Phase  II  or  when  : 
software  becomes  Co vernment - f ur ni shed  equipment. 

6.2.2  Schedule 


A  schedule  will  be  portrayed,  showing  when  configuration  identifi¬ 
cation  of  weapon  system  software  will  become  the  direct  responsibility  of  the 
Navy  SSA. 

6.3  CONFIGURATION  CONTROL 

Configuration  control  is  the  systematic  evaluation,  coordination,  approval 
or  disapproval,  and  implementation  of  all  approved  changes  in  the  configuration 
of  a  Cl  after  formal  establishment  of  its  configuration  identification. 

The  purpose  of  configuration  (change)  control  is  to  prevent  unnecessary 
or  marginal  changes  while  expediting  the  approval  of  those  that  are  necessary 
or  promise  significant  benefits  to  the  Covernroent.  Chonge  control  is  the  most 
visible  aspect  of  configuration  management,  since  personnel  engaged  in  this 
effort  evaluate  and  approve,  or  disapprove  proposed  changes. 

In  addition  to  change  decision  making,  change  control  will  include  the 
equally  important  factors  of  establishing  change  priorities  (emergency ,  urgent, 
routine),  and  of  assuring  that  necessary  instructions  and  funding  au thor ica t i or s 
are  issued  promptly  for  approved  changes.  During  the  acquisition  phase, 
changes  are  normally  processed  by  Faigineering  Change  Proposals  (ECPr),  usually 
submitted  by  the  cont rac t or (s ) ,  or  by  Software  Change  Proposals  (SCPs)  subnirtec 
by  the  using  Navy  Cormand.  Configuration  Change  Control  clauses  and  data 
requirements  shall  be  included  in  the  DD  Form  1423,  CDRL. 

6.3.1  Change  Proposals 

All  change  proposals  will  be  processed  in  accordance  with  MIL- FTI'- 4 FO  , 
MIL-STD-481  and  NAVA1KINST  4130.1.  The  SLCMP  will  contain  sample  forms,  sub- >  •_  i 
criteria,  and  representative  change  proposal,  distribution  lists.  Any  additional 
forms  or  requirements  for  data  over  and  above  that  required  by  M1L-STD-480  must 
be  listed  on  the  CDRL,  DD  Form  1423,  and  be  supported  by  an  approved  NAVA  I R  1 !  0 
DID.  Information  which  may  initiate  a  change  proposal  may  be  received  from 
the  foil  owing  sources: 

(a)  Chief  of  Naval  Operations 

(b)  Fleet  Users 

(c)  Systems  Command 

(d)  Test  and  Evaluation  Activities 

(e)  Navy  Laboratories 

(f)  Contractors 
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6.3.2  Change  Classification 

All  proposed  software  changes  vil '  le  categorized  with  regard  to  their 
Ispact  on  cite  operational  systca,  existing  documentation,  and  cost  effectiveness. 
Change  classification  shall  be  in  accordance  with  MIL- c‘rr'-480  requirements  as 
Interpreted  below  for  software. 

6. 3. 2.1  Definition  -  Categorization  of  change  actions  (In  accordance  with 
MIL* STD-480)  will  be  either  Class  I  or  Class  II  changes. 

6. 3. 2. 1.1  Class  I  changes  will  be  designated  whenever  one  or  more  of  the  following 
are  affected: 

a.  Operational  capability  (as  specified  in  the  baseline  or  as  part  of  the 
computer  software  Configuration  Item  (Cl)  specifications). 

b.  Contract  price  or  schedule. 

e.  Systems  equipment,  computer  programs,  or  facilities  produced  by  ocher 
contractor (s) ,  to  the  extent  chat  ocher  contractors  are  affected  and 
must  accomplish  a  change  to  maintain  compatibility  at  the  interface. 

Class  I  changes  will  be  submitted  to  the  Navy  in  accordance  with 
MIL- STD-480,  NAVAIRINST  4130.1,  and  the  SLCMP. 

6. 3. 2. 1.2  Class  II  changes  are  changes  Chat  the  developer  may  effect  after 
submittal  and  subsequent  concurrence  in  classification  by  the  SSA.  Such  changes 
may  include: 

a.  Changes  to  correct  editorial  errors. 

b.  Changes  to  correct  coding  errors. 

c.  Additions  of  clarifying  notes  or  diagrams. 

d.  Addition  or  correction  to  adaptation  data. 

e.  Recompiling  within  contractual  specified  limits. 

Copies  of  all  proposed  Class  II  changes  to  avionics  equipment  will 
be  submitted  through  the  local  Government  representative  (Defense  Contract 
Administrative  Services  Office  or  local  Navy  representative)  to  the  SSA, 
concurrent  with  their  submittal  to  XAVAIR  HQ.  Responsibility  for  concurrence 
in  classification  will  be  as  specified  in  the  contract. 

6.4  CONFIGURATION  CHANCE  PROCESS 

The  ehange  process  involves  the  preparation,  format,  submittal,  action, 
approval,  implementation,  and  distribution  of  software  changes  made  to  the 
approved  baseline. 
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6.4.1 


Input 


All  change  proposals  will  be  submitted  to  the  SCRB  by  the  SSA  for 
technical  approval/disapproval.  The  SSA  will  staff  all  change  actions  prio 
to  consideration  by  the  SCRB  except  in  unusual  circumstances. 

.1.2  Software  Change  Process  Flow 


The  SSA  will  identify  the  software  change  process  flow  in  detail. 
All  software  change  proposals  will  be  reviewed,  coordinated,  and  screened  for 
classification  and  analysis  by  the  SSA.  Analysis  of  the  software  change 
proposals  will  be  performed  by  the  SSA  or  a  designated  participating  field 
activity,  with  appropriate  contractor  support.  All  change  proposals,  with 
appropriate  operational  and  technical  analysis,  will  be  submitted  to  the 
Software  Change  Review  Board  for  review. 


6.4.3 


Software  Chance  Review  Board  (SCRB 


The  SCRB  referenced  in  Section  5. 2. 3.1,  is  responsible  for  weapon 
system  software  life  cycle  change  management  functions  as  follows: 

a.  Review  proposed  software  changes  and  provide  technical  approval/ 
disapproval  of  these  reviews. 

b.  Determine  overall  system  impact  of  proposed  change  and  assure  that 
computer  program  change  proposals  or  change  orders  cover  all  sub¬ 
systems  affected. 

c.  Provide  direction  to  the  SSA,  other  Navy  field  activities,  and 
development  contractors. 

d.  Provide  liaison  with  related  systems  ACCB,  CCCB,  and  SCRB  to  ensure 
compatibility  with  interfacing  systems. 


6.4.4 


Change  Implementation 


Change  implementation  responsibility  will  vary  depending  upon  life 
cycle  phase.  The  SUCH?  will  define  change  implementation  responsibility 
during  the  three  phases. 

6.4.5  Notices  of  Revision  (NOR 


NORs  for  software  changes  will  be  prepared  in  accordance  with 
MIL-STTK480  and  will  accompany  Class  I  and  Class  II  SCPs. 

6.5  CONFIGURATION  AUDITS 

Configuration  audita  are  performed  to  certify  compliance  with  config¬ 
uration  management  requirements.  The  audit  function  validates  accomplishment 
of  development  requirements  and  achievement  of  a  product  configuration  through 
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examination  of  the  Cl's  technical  documentation.  Two  kinds  of  audits  are 
performed,  functional  and  physical.  A  related  review  is  the  formal  quali¬ 
fication  review. 

a.  The  Functional  Conf Ir.urat ion  Audit  (FCA)  is  a  review  of  an  item's 

test/analysis  data  to  confirm  that  the  item,  as  designed  and  devel¬ 
oped,  meets  the  functional  performance  requirements  specified  in  its 
development  specification. 


b. 


The  Physical  Configuration  Audit  (FCA)  compares  the  "as  built"  iccm 
with  its  approved  and  released  technical  documentation  to  assure 
that  the  documentation  is  complete  and  is  appropriate  for  opera¬ 


tional,  maintenance,  and  support  purposes.  In  addition,  the  PCA 


establishes  the  product  baseline.  This  audit  is  vital  for  software 


and  computer  programs  because  the  Cl  specification  and  associated 


documentation  represent  the  complete  and  only  technical  description 
of  the  programs  "as  built". 


e.  The  Formal  Qualification  Review  (FOR)  is  a  "certified  FCA"  used  by 

NAVA1R  to  assure  that  the  item  design  is  sound  and  stable  enough  for 
spares  provisioning  and  ocher  logistic  support  purposes. 


6.5.1 


Purpose 


The  purpose  of  the  audit/review  function  is  to  validace  change 
implementation  accomplishments ,  and  to  certify  the  achievement  of  a  product 
through  configuration  item  technical  documentation.  Compliance  with  config¬ 
uration  management  requirements  will  be  verified  by  means  of  periodic  config¬ 
uration  audits  and  reviews. 


6.5.2  Frequency 


The  SLCMF  will  identify  the  frequency  of  configuration  audits. 


6.5.3 


Respons ib lllclcs 


The  SLCMP  shall  define  in  detail  ehe  responsibilities  of  the  acti¬ 
vities  involved  in  configuration  audits. 


6.5.4 


Reports 


The  SSA  will  report  to  Project  Management  the  results  of  all  con- 
placed  audits  and  copies  of  all  audit  reports  will  be  distributed  to  users. 

6.5.5  Field  Audits 


The  SLCMP  will  define  in  detail  ehe  procedures  used  to  assure  that 
users  are  operating  with  ehe  Navy  approved  software  baseline  and  documenta¬ 
tion.  The  SSA  will  be  responsible  for  management  and  implementation  of  field 
audita. 
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The  SLCMT  will  describe  rhr  detailed  procedures  for  the  recall/ 
return  of  noncurrom,  out-of-configuration  program  tapes  and  documentation. 

The  SSA  will  be  responsible  for  the  management  and  implementation  of  the 
product  recall. 

6.6  CONFIGURATION  STATUS  ACCOUNTING 

Configuration  status  accounting  documentation  is  the  means  through  which 
actions  affecting  Cls  are  recorded  and  reported  to  project  and  functional 
managers.  It  principally  records  the  "approved  configuration"  (baseline)  and 
the  implementation  status  of  changes  to  the  baseline.  It  is  the.  bookkeeping 
part  of  configuration  management  which  provides  managers  with  feedback  infor¬ 
mation  to  determine  whether  decisions  of  the  Change  Control  Board  (CCB)  are 
being  implemented  as  directed.  Configuration  status  accounting  has  its 
greatest  activity  after  establishment  of  the  Product  Configuration  Baseline 
(PCB)  when  formal  change  control  is  instituted. 

MIL-STD-482  contains  data  elements  to  be  used  in  the  accounting  and 
reporting  process.  Provisions  of  MIL-STD-482  allow  the  project  office  to  use 
any  data  contenc  and  format,  both  input  and  output,  necessary  to  perform 
status  accounting. 

6.6.1  Configuration  Status  Accounting  Records 

Software  configuration  baseline  status  accounting  requirements  will 
be  defined  in  the  SLCMP.  Status  accounting  records  will  be  consistent  with 
configuration  identification  and  shall  include  as  a  minimum: 

a.  Identification  of  initally  approved  product  baselines. 

b.  Identification  of  proposed  changes  to  configuration  items,  status  of 
such  changes,  and  identification  of  individual  or  organizational 
functions  responsible  for  deciding  upon  such  changes. 

c.  Identification  of  approved  changes  to  baseline  and  of  current 
configuration. 

6.6.2  Status  Reportlng/Rcsponsibilities 

The  SSA  will  prepare  the  status  summary  and  maintain  it  on  a  monthly 
basis.  The  status  summary  will  be  a  numerical  list  of  each  successive  change 
proposal  prepared  against  the  end  item  with  a  detailed  summary  of  the  status 
Information  for  each  change  proposal  which  is  currently  active. 
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7.0  QUALITY  ASSURANCE 

Quality  assurance  procedures  will  bu  established  to  systematically  ir  ■ 
that  the  quality  of  products  and  services  will  meet  the  needs  of  the  users  and 
be  in  accordance  with  applicable  military  standards,  approved  contractor  and/ 
or  military  specifications,  and  requirements  listed  in  the  SLCMT. 

A  thorough  Qualicy  Assurance  (QA)  Program  encompasses  many  tasks  and 
functions,  including  a  sound  concepc  formulation,  the  establishment  of  proper 
documentor ion/da ta  requirements,  and  timely  delivery  of  these  data  by  the 
contractor(s) .  The  primary  means  for  ensuring  ah  effective  QA  program  is 
through  proper  Test  and  Evaluation  (T&E)  throughout  the  design,  pilot  produc¬ 
tion,  and  production  phases  of  the  life  cycle.  KIL-Q-985S  provides  the  neces¬ 
sary  guidelines  for  the  tocal  QA  program;  NAVMATINST  3960.6  and  other  Navy  T&E 
Directives  provide  detailed  guidance  and  direction  for  all  T&E  requirements. 

Software/Computer  Resources  Verification,  Validation,  and  Certification 
(W&C)  is  an  approach  for  monitoring  and  evaluating  the  development  of  soft¬ 
ware  and  computer  programs.  VV&C  starts  at  the  beginning  of  the  software/ 
compucer  program  and  continues  throughout  the  program  life  cycle.  It  is 
closely  related  to  and  includes  Che  T&E  functions  commonly  associated  with 
systems  acquisition.  The  concept  is  generally  applied  in  the  use  of  Inde¬ 
pendent  evaluation  by  agencies  other  then  the  developer. 

This  section  shall  establish  a  system  of  activities  to  provide  the  quality 
of . products  and  services  that  will  meet  the  needs  of  users.  Management  pro¬ 
cedures  for  reviewing  and  evaluating  final  test  results  shall  be  defined. 
Guidance  for  creating  and  accomplishing  a  technically  adequate  quality  assur¬ 
ance  and  test  program  for  new  or  modified  software  and  computer  programs  shall 
be  provided. 

Computer  resources  testing  is  generally  governed  by  the  same  basic 
principles  that  apply  to  other  equipment  testing  and  is  discussed  only  In  its 
relation  to  and  effect  on  software  and  compucer  programs.  Additional  detailed 
guidance  for  developing  procedures,  selecting  test  cools  and  techniques, 
a"1?.,  ing  test  criteria  ar.d  standards,  and  conducting  evaluation  can  be  obtained 
from  NAVMATINST  3960.6  and  other  Navy  T&E  Directives. 

The  evaluation  criteria  (successful  test  criteria  or  accepc/rcject  limits) 
for  each  ccsc  shall  be  defined,  as  well  as  the  procedure  for  obtaining  approval 
of  test  results  by  the  procuring  agency. 

Developmental  milestones  shall  be  established  with  appropriate  testing  to 
verify  achicvcacnc  of  each  goal.  Validation/Ver if icacion/Cer cif ication  ccscs 
and  techniques  used  for  testing  shall  be  clearly  defined. 

7.1  DEVELOPMENT/MODIFICATION 

Quality  assurance  procedures  will  be  implemented  during  the  development 
and  SMdiflcacion  of  compucer  programs  and  will  be  strictly  adhetod  to. 
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Development  QA  must  include  rigorous  review  of  design  prior  to 
programming,  and  thorough  testing  of  individual  moaules  prior  to  integration 
in  the  overall  program,  to  avoid  a  build-up  of  errors  that  car.  ^c..ip^ur.d  during 
program  integration.  Developmental  milestones  will  be  established  and  appro¬ 
priate  verification/validation  testing  will  be  identified. 

7.1.2  S imulation 


Weapon  system  simulation  capability  will  be  developed  to  provide  the 
Navy  with  a  means  to  test  and  exercise  quality  assurance  over  all  software 
developed  during  the  software  life  cycle.  Consideration  should  be  given  to 
establishing  this  capability  early  in  Phase  1  for  the  purpose  of  conducting 
verification  and  validation  (tests)  at  the  Navy  SSA. 

7.1.3  Integration 

The  capability  for  integration  testing  of  newly  developed  or  modified 
software  into  the  total  weapon  system  environment  will  be  provided. 

7 . 2  VERIFICATION/ VALIDATION/ CERTIFICATION 

Verification,  Validation,  and  Certification  procedures  will  be  conducted 
to  assure  that  the  integrated  hardware/sof (ware  system  meets  all  testing 
requirements  in  accordance  with  SECNAVIKST  3560.1. 

7.2.1  Lab  Test 


Verification/validation  of  newly  developed  software  will  include 
integration  and  testing  with  necessary  elements  of  the  hardware  system  in  a 
laboratory  environment.  The  dcvcloper/support  activity  will  perform  labora¬ 
tory  testing  during  program  development.  The  developer  will  define  the 
configuration  of  the  laboratory  installation  and  document  the  difference  from 
the  weapon  system  production  configuration. 

7.2.2  Environmental  Testing 

Environmental  testing  will  exercise  the  software  in  the  weapon  system 
in  the  operational  environment.  System  Test  and  Diagnostic  software  will  be 
tested  by  actual  fault  insertion  with  faults  proportioned  to  weapon  system 
component  failure  rates  ar.d  program  complexity. 

7.3  TEST  AND  EVALUATION 

Following  any  developmental  change  or  modification  to  the  baseline  soft¬ 
ware,  the  new  computer  program  will  undergo  test  and  evaluation,  conducted  by 
a  designated  activity  other  than  the  computer  program  developer. 
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Activities  responsible  for  T&E  will  be  designated  and  applicable  instruc¬ 
tions  Tiic  SSA  and  responsible  Tili  activity  (s)  will  assist  NAVA l R  HQ 

in  the  preparation  of  a  Test  and  Evaluation  Master  Elan  (TDtT)  as  required  per 
NAVAIRINST  3960.2.  Sufficient  lead  tiec  and  monitor  effort  must  be  provided  to 
the  T&E  activity  to  permit  effective  software  T&E. 

Funding  requirements  for  the  supporting  T&E  activity  should  be  included 
in  the  funding  section  to  permit  total  cost  planning. 

7.3.1  Development  Test  and  Evaluation  (DT&E) 

Upon  completion  of  newly  developed  software,  DT&E  shall  be  the 
responsibility  of  a  developing  activity  organization  which  is  administratively 
and  technically  independent  of  the  actual  produce  engineering  process.  This 
DT&E  is  distinct  from  developmental  (in-process)  testing  conducted  by  the 
contractor  or  SSA. 

DT&E  focuses  on  the  technological,  engineering,  and  specified 
requirements  aspects  of  the  system  and  includes  an  operatenal  emphasis.  It  is 
Che  responsibility  of  the  development  activity  and  is  normally  completed  prior 
to  the  production  decision.  The  DT&E  effort  is  divided  into  the  two  areas  cf 
configuration  item  testing,  subsystem  test  and  system  test. 

DT&E  consists  of  the  determination  of  software  performance  in 
accordance  with  Program  Performance  Specifications  (PPS)  through  witness  of 
contractor  and/or  Navy  laboratory  tests  and  flighc  tcscing  conducted  by  the 
T&E  activity.  The  data  accrued  from  these  tests  will  be  used  by  the  devel¬ 
oping  activity  to  certify  the  systems  readiness  for  OPEVAL  in  accordance  with 
0PNAVIN3T  3960.10. 

7.3.2  Operational  Test  and  Evaluation  (OT&E) 

Operational  Test  and  Evaluation  (OT&E)  will  ba  conducted  by  Commander, 
Operational  Test  and  Evaluation  Forces,  or  his  designated  agent.  Normally  a 
Navy  activity  it  designated  as  an  operational  test  facility  which  reports  to 
the  CNO  on  che  operational  suitability  of  the  end  product. 

OT&E  addresses  Che  operational  effectiveness  snd  suitability  of 
systems  snd  equipment  under  realistic  operating  conditions.  For  all  new 
programs  and  chose  in  curly  phases  of  development.  Navy  T&E  Directives  require 
an  initial  phase  of  OT&E  to  be  accomplished,  called  Initial  Operational  Test 
and  Evaluation  (IOT&E)  prior  ts  the  production  decision.  OT&E  will  therefore 
peiaiicl  certain  phases  of  CTiS.  normally  the  system  level  testing.  Tcscing 
will  be  conducted  by  officially  designated  independent  agencies,  with  assis¬ 
tance  from  implementing  and  supporting  Cocsands. 

7.4  PRODUCTION 

Production  phase  quality  assurance  procedures  shall  provide  a  high  level 
of  confidence  in  che  uniform  high  quality  of  the  deliverable  media. 
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7.4.1  Software  Products 

All  deliverable  software  products  which  are  duplicated  from  con¬ 
trolled  and  tested  caster  copies  (magnetic  tape,  perforated  tape,  etc.)  will 
be  compared  with  that  master  copy  to  assure  exact  duplication.  All  duplicate 
sof  twarc  products  will  be  labeled  indicating  (1)  Serial  Number  of  the  master 
copy,  (2)  Date  of  duplication,  and  (3)  Completion  of  comparison. 

7.4.2  Library  Storage 


The  problem  of  storage  is  less  that  of  providing  a  repository  for 
the  physical  elements  of  the  software  (source  code,  test  data,  documentation, 
etc.)  than  it  is  of  providing  a  positive  means  for  recognising  related  elements 
(i.e.,  those  versions  which  constitute  a  particular  baseline)  and  for  protecting 
the  software  against  destruction  or  unauthorized  modification. 

A  comprehensive  identification  technique  which  ties  together  all  of 
the  different  forms  of  software,  will  be  provided.  Access  to  software  storage, 
particularly  for  replacement  or  deletion,  will  be  restricted  to  personnel 
authorized  to  perform  such  functions.  Physical  duplication  of  stored  software 
will  be  provided  as  necessary,  to  protect  against  failure  or  destruction  of 
the  storage  medium. 

7.4.3  Distribution 


Distribution  will  include ' provisions  that  will  enable  the  recipient 
to  confirm  that  delivery  was  complete.  He  will  also  be  informed  as  to  the 
method  of  installation  of  received  items  (revision  pages  in  a  document,  a 
computer  program  in  storage)  in  order  to  verify  that  installation  is  correct. 
Means  will  be  provided  to  enable  the  user  to  acknowledge  receipt,  installation, 
and  verification  activities,  and  to  quickly  report  any  problems  encountered. 
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8.0  SOFTWARE  DOCUMENTATION 


The  procurement  of  complete  and  accurate  technical. data  is  vital  to  th-> 
weapon  system  program  and  is  essential  to  meet  the  needs  of  design  review  and 
evaluation,  operation  and  maintenance,  and  further  procurements.  This  section 
will  establish  a  uniform  sec  of  requirements  for: 

a.  Specifications  for  all  software  and  computer  software  conf iguraclon 
Items. 

b.  User  oriented  documentation,  such  as  Computer  Program  User  Manuals, 
Operator  and  Maintenance  Manuals,  and  Programmer's  Notebooks. 

c.  Reports,  plans,  and  procedures  critical  to  the  design,  development, 
and  operational  usage  of  software  and  computer  resources. 

d.  Engineering  data  for  use  in  the  engineering  management  process,  such 
as  system  analyses,  trade  studies,  and  interface  control. 

Data  management  procedures  applicable  eo  all  functional  areas  that  govern 
and  control  Che  generation  and  delivery  of  data,  are  required  subsequent  to 
procurement  of  sofcvarc  documentation.  Data  management  procedures  will  ba 
compatible  with  current  NAVA IX  HQ  and  DoD  policies. 

To  assure  that  all  of  the  required  supporting  documentation  is  available 
at  one  central  location,  the  SSA  will  be  designated  as  the  software  documenta¬ 
tion  control  activity  for  tactical  software.  The  SSA  shall  also  maintain  (for 
working  references)  up-to-date  copies  of  documentation  utilized  by  Naval  Air 
Rework  racilities/Cognizant  Field  Activities  (NAVAIRRLVOKXFAC/CFA)  in  -heir 
ATE  cape  maintenance  role. 

8.1  SSCNAVINST  3560.1 

SECNAVIKST  3560.1  establishes  a  uniform  sec  of  requirements  for  the 
preparation  of  digital  computer  program  technical  documentation. 

8.1.1  Design  Documentation 

The  Software  Documentation  specified  in  Che  contract  will  be  based 
on  SECNAVINST  3560.1.  All  design  documentation  requirements  will  be  specified 
in  the  CDRi.  and  will  be  supported  by  approved  NAVAIR  HQ  DIDs. 

8.1.2  User  Documentation 


The  user  documentation  specified  ih  Che  contract  will  be  based  on 
SECNAVINST  3560.1.  All  user  documentation  requirements  will  be  specified  in 
the  CDRL  and  will  be  supported  by  approved  NAVAIR  HQ  DIDs. 

8.2  INTERIM  DOCUMENTATION 

Interim  documentation  shall  be  as  specified  in  NAVA1RINST  5230. 3A. 
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8.3  DELIVERY 

Tills  section  will  identify  the  documentation  to  be  delivered  under  the 
contract.  In  addition,  this  section  will  contain  a  detailed  delivery  schedule. 

8.3.1  Contract  Data  Requirements  List  (CDRL) 

All  data  required  as  deliverable  items  shall  be  specified  by  the 
DD  Form  1423,  Contract  Data  Requirements  List. 

8.3.2  Data  Item  Description  (DID) 

The  contents  of  each  data  item  required  by  the  CDRL  shall  be  described 
in  detail  by  an  approved  KAVAIR  HQ  Data  Item  Description  (DID).  A  listing  of 
the  more  essential  DIDs  will  be  provided  in  the  KAVAIR  Software  Management 
Manual  (to  be  developed).  In  addition  to  items  directly  related  to  software 
and  computer  resources,  items  which  contain  provisions  or  constraints  impacting 
these  resouces  are  also  listed.  Specific  procurements  may  require  the  prepa¬ 
ration  of  unique  DIDs  to  meet  the  specific  system  requirements.  These  unique 
DIDs  must  be  approved  by  KAVAIR  HQ  prior  to  utilization. 

8.4  SECURITY  OF  CLASSIFIED  MATERIAL  (SOFTWARE) 

The  procedure  to  be  followed  to  determine  the  classification  of  software 
and  to  ensure  the  integrity,  proper  storage,  transportation,  and  handling  of 
software  classified  material  vill.be  stated  in  the  SLCMP.  These  procedures 
shall  be  in  accordance  with  the  current  Industrial  Security  Manual  for  Safe¬ 
guarding  Classified  Information  (DoD  5220. 22M). 

8.5  DATA  MANAGEMENT 

The  Navy  will  monitor  the  contractor's  or  developing  activity's  software 
documentation  effort  throughout  the  Development  Phase  (Phase  I)  to  assure  that 
the  documentation  delivered  to  the  Navy  will  meet  contract  specifications. 

This  will  be  accomplished  by  using  standard  in-process  reviews.  The  SSA  will 
be  the  official  computer  software  documentation  agency  to  ensure  that  rll  of 
the  required  supporting  documentation  is  available  in  one  central  location, 
and  that  adequate  quality  control  is  maintained. 

Data  Management  is  applicable  to  all  functional  areas  and  comprises  a  set 
of  procedures  and  disciplines  chat  govern  and  control  the  generation  and 
delivery  of  data.  The  types  of  data  required  for  a  program  are  directly 
dependent  upon  the  management  disciplines,  techniques,  and  procedures  imposed 
and  the  level  of  visibility  and  traceability  required.  The  SSA  Data  Manage¬ 
ment  Program  will  be  compatible  with  current  NAVAIR  HQ  and  DoD  policies. 


8.5.1 


Sof tvare /Document ation  Library 


HAVA I R IN ST  5230.5 
21  Jul  1976 

8.5.2  Inventory  Concrol  and  IHscribuClon 

An  inventory  control  sync cm  will  be  created  to  assume  responsibility 
for  overall  software  material  management  and  concrol  of  all  stock  and  unde¬ 
livered  assets.  Manac.i-ncnt  will  include  tlic  responsibility  for  preparation 
and  distribution  of  allowance  lists,  initial  outfitting  lists,  as  well  as 
planning,  programming,  inventory  reporting,  stock  coordination,  disposal,  and 
other  functions  that  arc  necessary  for  control  of  all  program  assets.  Speci¬ 
fic  functions  will  be: 

a.  Preparation,  distribution,  and  updating  of  allowance  and  initial 
outficcing  lists  for  inclusion  in  the  Integrated  Logistic  Support 
Management  Plan  (ILSMP). 

b.  Maintenance  of  a  master  data  file  of  technical  appLicacion  and 
inventory  management  information. 

c.  Maintenance  of  a  master  tape  storage. 

d.  Coordination  of  a  master  cape  reproduction  capability. 

A  discrlbucion  concrol  system  thee  will  be  responsive  to  operational 
requirements  will  be  developed.  This  system  will  be  cailorcd  to  fit  the 
peculiar  nacure  of  software  and  will  be  Che  central  control  poinc  for  the  dis¬ 
tribution  of  program  assecs. 

8.6  GOVcRl.TtcNT  PREPARED  DOCUMENTS 

The  SSA  will  provide  source  information  and  assist  in  the  generation  and 
management  of  any  Government  prepared  document  relating  to  the  control  of 
weapon  system  software.  This  section  of  the  SLC1P  will  ineluda  a  Government 
Furnished  Information  (CrI)  Schedule. 

8.7  SUPPORTIVE  TECHNICAL  DOCUMENTATION 

The  SSA  will  provide  source  information  and  assist  the  cognizant  publi¬ 
cations  manager  for  NATOPS  Manuals,  Tactical  Manauais,  3nd  Maintenance  Manuals, 
in  updating  these  manuals  co  reflect  the  latest  computer  software  configuration. 
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1.0  CENERAL 

Voluac  H,  Section  2.0  of  i.ne  SlCMP  will  identify  all  resources  required 
for  Immediate,  continuing,  and  future  software  life  cycle  support.  This 
section  will  identify  the  resources  and  responsibilities  for  computer  program 
and  ocher  software  resources  management,  including  computer  program  types, 
modification  processing  procedures,  and  interfaces  between  using  and  sup¬ 
porting  commands.  Resources  include  personnel,  equipment,  facilities  (build¬ 
ings,  laboratories,  maintenance  facilities,  test  ranges,  etc.)  and  the  funds 
to  support  chc  above.  This  section  will  identify  "what"  is  needed  and  when  it 
is  needed.  Ail  facilities  and  resource  requirements  shall  be  requested  from 
AIR-06. 

2.0  FACILITIES 

Facilities  requirements  will  be  identified  and  defined  in  the  SLCMP  to 
permit  the  weapon  system  Project  Manager  to  plan  effectively  and  meet  program 
requirements  in  a  timely  and  orderly  manner. 

2.1  Military  Construction  (MILCON) 

Requirements  for  new  construction,  or  for  expansion  and/or  major  modifi¬ 
cation  of  existing  facilities  to  provide  the  necessary  sofevare  life  cycle 
support  will  be  identified  and  defined  In  the  SLCMP.  The  SLCMP  will  specify 
when  these  facilities  arc  required,  what  capabilities  they  will  provide,  and 
Che  funding  chat  will  be  required.  MILCON  documentation  development  and 
approval  cycle  will  be  considered  in  establishing  planning  and  facility 
definition  schedules. 

2.2  Lab  Facilities 

Laboratory  facilities  required  to  provide  software  life  cycle  support 
will  be  described  in  this  section. 

2.3  Test  Ranges 

The  SLCMP  will  identify  and  define  the  types  of  test  range  facilities, 
recording,  and  instrumentation  equipment  required,  the  need  dates,  and  the 
objectives  to  be  attained  utilising  the  range  facilities.  This  section  will 
include  provisions  for  coordination  of  test  range  requirements  with  the  NAVAIR 
HQ  Test  and  Evaluation  Coordinator. 

3.0  EQUIPMENT 

The  SLCM?  will  identify  and  define  the  equipment  required,  the  need 
daces,  the  capability  to  be  established,  and  the  funds  required  to  provide  the 
necessary  equipment.  Equipments  are  to  include  laboratory  equipment,  opera¬ 
tional  computers,  associated  avionics  equipment,  and  test  equipment.  Addi¬ 
tionally,  support  aircraft  resources  will  be  identified. 


Enclosure  (l) 


NAVAIRINST  5230. 5 
21  Jul  1976 

3.1  ADP  Acquisition 

Requirements  for  ADP  equipment  will  be  identified  in  the  SLCMP.  Recom¬ 
mendations  for  the  most  cost  effective  means  of  providing  the  required  ADI’ 
equipment  (purchase  or  lease)  will  be  identified. 

3.2  Hardware 

The  hardware  required  to  provide  a  complete  and  viable  system  for  support 
ing  the  software  life  cycle  will  be  detailed  in  the  SLCMP.  Long  acquisition 
lead  times  and  shortage  of  assets  will  be  carefully  considered  and  planned  for 
in  this  requirement.  The  SLCMP  shall  have  provisions  for  logistics  support 
via  the  Weapons  Systems  Planning  Document  (WSPD). 

3.3  Aircraft 

Aircraft  requirements  to  support  flight  testing  and  demonstrations  will 
be  identified,  defined,  and  justified  in  the  SLCMP.  Provisions  for  coordi¬ 
nation  of  aircraft  requirements  with  designated  KAVAIR  acitivities  will  be 
Included  in  this  section.  Aircraft  resources  will  be  requested  from  AIR-06. 

4.0  SUPPORT  SOFTWARE 

The  SLCMP  will  Identify  sad  define  the  support  software  required,  the 
need  daces,  the  capability  to  be  established,  and  the  funds  required  to 
provide  the  necessary  software  support. 

5.0  MANPOWER 

All  manpower  requirements  identifying  special  skills,  training,  staffing 
levels,  and  contractor  support  will  be  identified  end  defined  in  the  SLCMP. 

5.1  Special  Skills 

All  requirements  for  special  skills,  training,  staffing  levels,  and 
contractor  support  will  be  identified  and  defined  in  the  SLCMP.  Software  and 
computer  resources  have  unique  support  requirements  in  specialized  personnel 
skills  that  require  identification  during  the  initial  planning  phase  to  ensure 
adequate  lead  times  for  training.  Seme  of  the  more  essential  skills  required 
to  support  the  weapon  system  software  and  computer  resources  are  as  follows: 

a.  Technical  management  capability  for  overall  Integration  of  program 
modifications ,  determination  of  priorities,  establishment  of  bounds 
on  problems  identified  by  user  commands,  and  coordination  of  activi¬ 
ties  between  system  manager  and  engineering. 

b.  Ability  to  develop  revised  equations,  to  set  up  the  equations  into 
loglcsl  steps  to  be  used  by  the  computer,  and  to  perform  the  actual 
coding  to  be  used. 
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c.  The  specialized  testing  of  computer  programs  and  ocher  supporting 
software  using  Che  integrated  support  facility  to  evaluate  new 
programs.  This  specialty  involves  actual  operation  of  systems 
equipment  and  proviacs  necessary  technical  direction  of  support 
facility  maintenance  by  computer  technicians. 

d.  The  ability  to  analyze  and  evaluate  the  performance  of  the  computer 
program  and/or  other  software  using  data  acquired  in  testing,  to 
establish  that  modified  prograsis  perform  as  intended. 

e.  The  engineering  ability  to  Interface  the  computer  operation  with 
other  system  elements  (whereas  programing  (b)  is  concerned  with  the 
operation  of  the  software  program  itself). 

t.  The  knowledge  and  ability  for  routine  maintenance  and  operation  of 
Che  equipments  which  comprise  the  integrated  support  facility. 
Including  trouble-shooting,  and  repair  of  system  components,  within 
the  facility. 

6.0  SUPPORT 

The  requirements- for  Integrated  Logistics  Support  or  special  support  will 
be  identified  in  detail  la  the  SLDtP. 

6.1  Integrated  Logistics  Support  Plan  (1LSP)  Input 

The  interface  and  impact  of  the  SLOtP  on  the  ILSP  will  be  defined  in  this 
section. 

6.2  Special  Requirements 

Special  support  requirements  will  be  defined  in  the  SLCfP. 
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"ESTABLISHMENT  OF  TACTICAL  SOFTWARE  CHANGE 
REVIEW  BOARDS  (SCRB)" 

ABSTRACT 


•  Provides  for  the  establishment  of  Software  Change  Review  Boards. 

•  Provides  a  Software  Change  Review  Board  Charter. 

•  Identifies  Software  Change  Review  Board  Guidance  Documents. 


DEPARTMENT  OP  THE  NAVY 
NAVAL  AIR  SYSTEMS  COMMAND 
WASHINGTON,  D  C.  20361 


NAVAIR  INSTRUCTION  3230.6 

From:  Commander,  Naval  Air  Systems  Command 


•h  »t»  in  to 

KAVAIRINST  5230  6 
AIR-5331 
1  Jun  1977 


To:  Deputy  Commander,  Assistant  Coraaanders,  Comptroller,  Command  Special 

Assistants,  Deputy  Commander,  Designated  Project  Managers,  Project 
Coordinators,  and  Office  and  Division  Directors 

Subj:  Establishment  of  Tactical  Software  Change  Review  Boards  (SCRB) 

Ref:  (a)  NAVMAT1NST  4130. 1A 

Cb)  NAVMATINST  4130. 2A 

(c)  NAVA1RINST  4130.1 

(d)  KAVAIRINST  5230.4 

(e)  KAVAIRINST  5230.5 

End:  (1)  Software  Change  Review  Board  Charter 
(2)  List  of  SCRB  Guidance  Documents 

1.  Purpose.  This  instruction  provides  for  the  establishment  of 
Software  Change  Review  Boards  (SCRB)  by  Project  Managers  (PM)  or 
Acquisition  Managers  (AM)  as  a  management  discipline  to  exercise 
configuration  control  over  weapon  system  tactical  digital  processor 
software  and  related  support  software. 

2.  Background.  In  recent  years  the  weapon  systems  control  functions 
have  been  enhanced  by  the  introduction  of  digital  computer  technology. 
Inherent  in  the  use  of  digital  computer  technology  is  the  ability  to 
change  system  operational  capability  by  modification  of  the  computer 
software  programs  alone.  The  relative  ease  with  which  such  computer 
program  changes  can  be  effected  (compared  to  hardware  modifications) 
provides  a  high  degree  of  flexibility  in  responding  to  new  Fleet 
requirements.  This  ease  of  change  requires  a  responsive  software 
configuration  management  organisation  with  the  operational  and  technical 
knowledge  to  evaluate  proposed  changes  and  to  ensure  expeditious  imple¬ 
mentation  for  Fleet  support.  Reference  (a)  provides  statements  of 
policy,  implementing  guidance,  and  procedures  governing  Configuration 
Kanagment  (CM)  in  the  Department  of  the  Navy.  Reference  (b)  clarifies 
responsibilities  of  Systems  Commanders  and  Project  Managers  for  control 
and  coordination  of  changes  to  tactical  and  technical  computer  programs. 
Reference  (c)  implements  reference  (a)  and  contains  the  primary  policy 
and  procedures  governing  CM  in  the  Naval  Air  Systems  Command  (KAVAIR). 
Reference  (d)  designated  the  Director  of  the  Avionics  Division  (AIR-533) 
as  the  mama gar  of  all  NAVAIR  weapon  system  tactical  digital  processors 
and  related  software. 
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3.  Tcrminolopy 

a.  For  purposes  of  this  instruction,  the  tcra  "tactical  digital 
processor^)  and  related  software"  includes  only  the  airborne  processor(s) 
and  the  operational  prograra(s)  with  their  concomitant  host  system(s)  and 
development  facilities. 

b.  Digital  processors  are  special  or  general  purpose  digital  computers 
which  accept  data  inputs,  process  these  inputs  in  accordance  with  a  stored 
set  of  ordered  arithmetic  and  logic  instructions,  and  output  data  or  commands 
to  external  devices. 

c.  Digital  processor  programs  are  the  set  of  ordered  arithmetic 

and  logic  instructions  together  with  the  data  on  which  these  instructions 
operate.  The  program  nay  be  scored  (1)  on  peripheral  storage  devices, 

(2)  in  electrically  alterable  memory,  (3)  in  non-alterable  memory  or 
(4)  any  combination  thereof. 

d.  Concomitant  host  systems  are  those  systems  which  support  the 
development,  test  and  evaluation,  and  generation  of  digital  processor 
programs.  For  chese  purposes  the  host  system  includes  computers 
(military  or  commercial);  the  necessary  assemblers,  compilers  and 
other  support  software;  and  ancillary  equipment  such  as  tape  drives, 
discs,  etc.  Development  facilities  include  that  combination  of  actual 
avionics  equipment  and  stimulation/simulation  equipment  as  necessary 
to  ensure  proper  integration,  checkout  and  evaluation  of  the  generated 
digital  processor  program. 

e.  Software  is  all  digital  processor  programs  together  with  all 
program  design  and  user  documentation. 

4.  Applicability 

a.  The  requirements  for  SCRB  set  forth  in  this  instruction  apply 
to  all  weapon  system  tactical  digital  processor  software  and  related 
support  software  (GFE  or  CFE)  which  are  the  responsibility  of  Naval  Air 
Systems  Command  Headquarters  (NAVAIR  HQ). 

b.  Excluded  from  the  provisions  of  this  instruction  are  management 
information,  logistics,  command  support  type  applications  and  Automatic 
Test  Equipment  software. 

5 .  Responsibility 

a.  The  Avionics  Division  (AIR-533)  shall  provide  coordination  and 
assistance  in  the  application  of  this  instruction. 

b.  The  PM/A>:  may  establish  a  SCR3  in  the  validation  phase  when  in 
his  judgment  the  system  is  of  such  magnitude  or  '  iportsnce  that  prudent 
judgment  indicates  that  formal  coordination  and  review  of  proposed  softwar 
changes  are  necessary  to  protect  the  Command's  interests. 
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c.  In  the  full  scale  development  phase,  a  SCRB  shall  be  established 
by  the  PM/AM  when: 

(1)  The  weapon  system  tactical  digital  processor  softuare  is  of 
such  magnitude  or  importance,  or  of  such  a  nature,  that  prudent  judgment 
indicates  that  formal  coordination  and  review  of  proposed  software 
changes  are  necessary  to  protect  the  Command's  interests. 

(2)  The  software  change  matters  to  be  resolved  are  complex  and 
require  the  participation  and  recommendations  of  several  NAVAIR  RQ 

d ivisions / of  f ices . 

d.  In  any  event  a  SCRB  shall  be  established  prior  to  fleet  introduction 
unless  prudent  judgment  indicates  that  formal  coordination  and  review,  by  all 
affected  organizations  and  activities,  is  not  necessary. 

e.  In  the  event  a  decision  is  made  not  to  establish  a  SCRB,  all  software 
change  proposals  shall  he  processed  in  accordance  with  reference  (c). 

6.  Action 


a.  Project  Managers/Acquisition  Managers  shall  establish,  as  appropriate, 
a  SCRB  for  the  tactical  digital  processor  software  and  related  support 
software  of  each  weapon  system  for  which  he  has  cognizance.  Enclosure 
(lj  sets  forth  the  elements  of  a  Software  Change  Review  Board  Charter. 

Each  SCRB  established  shall  be  chartered  in  accordance  with  this  instruction. 

The  charter  shall  become  a  part  of  the  appropriate  Software  Life  Cycle  Management 
Plan  prepared  in  accordance  with  reference  (e).  Enclosure  (2)  sets  forth  SCRB 
Guidance  Documents. 


b.  Project  Managers/Acquisition  Managers  shall  budget  and  direct 
the  necessary  funding  to  support  each  SCRB  which  he  establishes. 

c.  AIR-533  shall  provide  proper  and  timely  coordination  and  assist¬ 
ance  in  response  to  the  needs  of  the  Project  Manager/Acquisition  Manager 
in  establishing  a  SCRB. 


d.  The  implementation  of  this  instruction  by  addressees  shall  not 
be  cause  for  reformatting  existing  software  management  boards  which 
fulfill  the  requirements  of  this  instruction.*  however ,  the  £p*«qion 
of  all  future  SCRB's  shall  conform  to  this  instruction. 


T.  H.  BAUGHMAN 
Vice  Commander 
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SOFTWARE  CHANGE  REVIEW  BOARD  CHARTER 


1.  Charter.  Under  direct  charter  from  the  Chief  of  Naval  Operations 
and  the  Chief  of  Naval  Material,  NAVAIP.  is  responsible  for  providing 
Fleet  activities  with  effective  systems  to  satisfy  Fleet  operational 
requirements.  Computer  software  systems  are  provided  by  NAVAIR  to  help 
satisfy  these  requirements.  A  Software  Change  Review  Eoard  (SCRB)  is 
chartered  and  established  to  support  the  Project  Manager  (PM)  or 
Acquisition  Manager  (AM)  in  exercising  configuration  control  of  the 
software  system.  The  SCRB  functions  in  a  technical  advisory  capacity  to 
the  PM/AM.  To  provide  this  advisory  capability  for  all  aspects  of  a 
system  software,  the  membership  of  the  SCRB  shall  be  composed  of 
representatives  of  all  Navy  technical,  user  and  support  activities  and 
all  -  nt  actor  organizations  cognizant  of  the  system  software  life- 
cycle.  SCRB  members  will  review  and  evaluate  all  proposed  changes  to 
system  software  to  assess  impacts  in  their  areas  of  expertise  and  will 
recommend  disposition  to  the  SCRB  Chairman.  The  SCRB  Chairman  shall 
report  all  SCRB  findings  to  the  PM/AM  by  written  synopsis.  The  PM/AM 
has  the  final  authority  in  the  implementation  of  software  changes. 

Factors  such  as  budgetary  constraints,  system  needs,  implementation, 
test  schedule,  fleet  release  schedule,  other  system  priorities,  and* 
impact  on  interfacing  systems  will  determine  which  software  changes  are 
implemented. 

2.  Authority  of  a  SCRB 

a.  A  SCRB  is  required  to  make  recommendations  to  the  PM/AM  on  all 
substantive  matters  relating  to  the  weapon  system  tactical  digital 
processor  software  and  related  support  software.  Consequently,  organi¬ 
zations  appointing  members  to  a  SCRB  shall  ensure  that  such  members  are  * 
qualified  and  authorized  to  make  technical  assessments  affecting  the 
interests  of  their  organizations,  generally  without  reference  to  higher 
authority. 

b.  A  SCRB  is  authorized  to  call  upon  and  shall  be  supported  by  any 
division/office  of  NAVAIR  HQ.  The  division/office  shall  furnish  information, 
advice,  or  other  assistance  necessary  to  support  the  SCRB  in  its  delib¬ 
erations.  Nothing  in  this  instruction  shall  be  construed  as  affecting 

the  responsibility  of  the  PM/AM.  * 

3.  Organization  of  a  SCRB 

a.  The  SCRB  shall  consist  of  voting  members  from  each  of  the  following 
areas  as  appropriate: 

(1)  Project  Kaneger/Acquisition  Manager 
(a)  SCRB  Chairman 

(2)  AIR-04 

(3)  AIR-05 

(4)  AIR-06 

(5)  Navy  Field  Activities 
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(6)  Navy  Software  Support  Activity  (SSA)  or  Designa  ad  Life 
Cycle  Support  Activity 

(a)  SCRB  Secretariat 

(7)  Fleet  Major  Command  Software  Representatives 

b.  The  SCRB  may  consist  of  non-voting  advisors  from  each  of  the 
following  areas,  as  appropriate: 

(1)  Contractors 

(2)  Interfacing  systems  SCRB  representative (s) 

(3)  Operational  Test  and  Evaluation  Forces  Representatives 

c.  The  SCRB  may  consist  of  subcommittees  for  each  major  software 
program  utilized  by  a  weapon  system  (i.e..  Tactical  Subcomittee ,  On- 
Board  system  test  subcommittee,  etc.).  The  subcommittee  members  shall 
consist  of  voting  members  and  non-voting  advisors  as  specified  in  paragraphs 
3(a)  and  3(b). 

d.  Where  their  participation  in  specific  cases  is  considered  necessary, 
representatives  from  other  divisions/offices  of  NAVAIR  HQ  shall  serve  as 
advisors  to  the  board  as  required  by  the  Chairman.  Members  may  be 
assisted  by  such  other  personnel  as  they  consider  advisable  or  necessary. 

4 .  Functions  of  a  SCRB 


a.  General  Guidance  for  SCRB  Activities 


(1)  Proposed  changes  shall  be  coordinated  with  and  evaluated  by 
affected  organization (s)  prior  to  approval. 

(2)  Factors  such  as  performance  guarantees,  ground  support 
equipment  interfaces,  ocher  platform  or  sensor  interfaces,  training 
equipment.  Automatic  Test  Equipment  software  interfaces,  implementation 
cost  and  value  engineering  will  be  identified  in  the  software  change 
review  evaluation. 

(3)  When  a  proposed  change  affects  any  system  or  item  under  the 
cognizance  of  another  service,  command,  project,  or  program,  the  proposed 
change  shall  be  coordinated  with  persons  in  that  service,  command, 
project,  or  program  having  cognizance  of  the  system  or  item  affected. 
Joint  SCRB  meetings  shall  be  held  when  required. 

(4)  Proposed  changes  submitted  for  SCRB  action  shall  be  complete 
with  respect  to  technical  requirements,  justification,  cost  information, 
logistics  requirements,  interface  requirements/impacts,  retrofit  and 
other  applicable  information. 

(5)  Particular  attention  must  be  given  to  the  funding  and  total 
cost  aspects  of  changes. 

(a)  The  SCRB  shall  identify  funding  requirements,  tradeoffs 
and  priorities  to  the  PM/AM  for  funding  allocation. 
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(b)  In  addition  to  direct/imr.ediurc  coses  of  changes,  the 
cost  of  logistics  support,  involving  obsolescence  or  nodi : icat ion  of 
technical  data,  revisions  to  manuals  and  publications,  and  codifications 
to  rapes,  trainers,  etc.,  will  be  identified- 

(6)  Status  reports  of  proposed  changes  produced  by  th?  Software 
Support  Activity  (SSA)  shall  be  reviewed  and  evaluated. 

(7)  The  SCRB  shall  ensure  that  the  affect  of  proposed  changes  on 
foreign  military  sales  programs  have  been  considered. 

(8)  As  a  Tesult  of  SCRB  actions  resulting  in  the  scheduling  of 
a  new  baseline  program  for  fleet  issue,  assure  that  all  affected  areas 
of  change  have  been  addressed  and  a  software  Engineering  Charge  Proposal 
has  been  prepared  for  processing  in  accordance  with  KAVAIFcINST  4130.1 
prior  to  fleet  release. 

b.  SCRB  Chairman.  Ultimate  authority  for  the  SCRB  rests  with  the 
PM/AM.  The  SCRB  Chairman  shall  be  appointed  by  the  I'M /AM  to  act  as  his 
agent  in  all  SCRB  functions.  The  SCRB  Chairman  shall  report  all  SCRB 
findings  to  the  PM/ AM.  The  responsibilities  of  the  SCPJS  Chairmen  ere  as 
follows: 


(1)  Schedule  and  conduct  SCRB  meetings. 

(2)  Ensure  that  notice  of  8  SCRB  Deeting  is  furnished  suffi¬ 
ciently  in  advance  so  that  representatives  may  attend  completely  prepared. 

(3)  Ensure  that  AIRTASlCS,  work  unit  assignments  and  contract 
changes  are  issued  to  fund  SCRB  members  for  direct  SCRB  participation. 

(4)  Consolidate  budgetary  estimates  of  SCRB  members  for  proposed 
software  changes. 

(5)  Evaluate  and  act  on  proposed  software  changes. 

(6)  Present  recommended  changes  to  PM/AM  to  assist  him  in 
determining  which  change  requests  will  be  processed  for  implementation. 

(7)  Coordinate  implementation  of  software  changes  approved  by 
the  PM/AM. 

(5)  Present  composite  software  Engineering  Change  Proposal 
for  new  baseline  fleet  issue  programs  to  the  appropriete  Change  Control 
Board  (CCB)  in  accordance  with  NAVAIRINST  4130.1. 

(9)  Coordinate  Navy  testing  of  software  changes. 

(10)  Sign  the  written  synopsis  of  matters  considered  and  recocenen- 
dations  made  by  the  Board.  (The  synopsis  shall  be  made  a  permanent  part 
of  the  proceeding  of  the  SCRB  ant*  copies  of  the  synopsis  should  be 
distributed  to  all  SCRB  members): 
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c.  SCRB  Secretariat.  The  Software  Support  Activity  (SSA)  will 
provide  a  Secretariat  to  perform  administrative  functions  including: 


(1)  Receiving,  recording,  comoiling,  and  distributing  of 
proposed  changes. 

(2)  Preparing,  coordinating  and  distributing  the  SCRB  agenda. 

(3)  Acting  as  recording  secretary  during  the  SCR3  meeting. 

(4)  Preparing  the  composite  software  Engineering  Change  Proposal. 

(5)  Performing  additional  staffing  functions  as  directed  by  tbe 
SCRB  Chairman. 

(6)  Preparing  and  distributing  written  synopsis  of  matters 
considered,  recommendations  made  by  the  Board,  action  items,  and  status 
reports  of  proposed  changes. 

(7)  Distributing  copies  of  signed  synopsis  to  all  SCRB  members. 

d.  Other  SCRB  Members.  All  SCRB  members  will  represent  their 
respective  activities  regarding  all  proposed  software  changes  brought 
before  the  Board.  Their  duties  include  the  following: 

(1)  Review,  evaluate  and  coordinate  with  other  offices  as 
required  to  determine  impact  of  all  proposed  changes. 

(2)  Attend  meetings,  as  required,  of  the  full  SCRB  to  present 
a  position  statecent  on  proposed  changes. 

(3)  Assist  in  the  preparation  of  composite  software  Engineering 
Change  Proposal  to  the  appropriate  CCB  for  approval  prior  to  release  of 
a  new  baseline  fleet  issue  program. 

(4)  Assist  the  SSA  in  analysis  of  the  impact  of  proposed  changes 
as  appropriate. 

(5)  Perform  other  tasks  as  assigned  by  the  SCRB  Chairman. 

5.  General  Procedures  for  Processing  Proposed  Changes 

a.  Proposed  Changes.  Proposed  changes  to  software  systems  may 
arise  from  the  following  sources: 

(1)  Chief  of  Naval  Operations. 

(2)  Fleet  users. 

(3)  Systems  Command. 

(4)  Test  and  Evaluation  Activities. 

(5)  Navy  Laboratories. 

(6)  Contractors. 
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b.  Minimum  Content  Requirement  of  Proposed  Clinches.  Trie  mir.inua  Lnformat  ion 
to  be  set  forth  in  a  proposed  change  shall  be: 

(1)  Originator  Kane /Address  ■'Telephone  No. 

(2)  Type  of  change. 

(3)  Title  of  change. 

(4)  Priority. 

(5)  System  identification  -  Kodel/Type. 

(6)  Configuration  Item  Identification/Software  Program 
Identification  -  No. /Noaenclature. 

(7)  Other  systeos/subsysteos/conf iguration  items  affected. 

(8)  Documentation  Affected  -  Spec. /Doc.  No. 

(9)  Description  of  change  requested  or  trouble  reported. 

(10)  Need  for  change 

(11)  Recommended  effective  date 

(12)  Submitting  activity  authorizing  signature/title/date. 

c.  Submission  of  Proposed  Changes.  Proposed  changes  shall  be  submitted 
concurrently  to  the  PM/AK  and  the  SSA. 

d.  Priorities.  Proposed  changes  shall  be  assigned  priorities  of 
either  esergency,  urgent,  or  routine  by  the  originator. 

(1)  Emergency.  This  priority  shall  be  assigned  to  changes 
proposed  for  any  of  the  reasons  listed  in  subparagraphs  (a)  and  (b) 
below.  Replies  to  eoergency  proposed  changes  shall  be  made  within 
twenty-four  (24)  hours  of  proposal  receipt. 

(a)  To  effect  a  change  in  operational  characteristics 
which,  if  not  accomplished  without  delay,  may  seriously  compromise 
national  security. 

(b)  To  correct  a  hazardous  condition  which  may  result  in 
fatal  or  serious  injury  to  personnel,  or  in  extensive  daoage  or  destruc¬ 
tion  of  equipment.  A  hazardous  condition  usually  will  require  withdrawing 
the  item  froa  service  temporarily,  or  suspension  of  the  ten's  operation, 
or  discontinuance  of  further  testing  or  developaent  pending  resolution 

of  the  condition. 

(2)  Urgent.  This  priority  shall  be  assigned  to  changes  proposed 
for  any  of  the  reasons  listed  in  subparagraphs  (a)  through  (e)  below. 

Replies  to  urgent  SCR  or  STR  shall  be  made  within  fifteen  (13)  calendar  days 
of  proposal  receipt. 

(a)  To  effect  a  change  in  operational  characteristics 
which,  if  not  accomplished  expeditiously,  may  seriously  comproaise  the 
aission  effectiveness  of  deployed  equipment. 

(b)  To  correct  a  potentially  hazardous  condition  which 
cay  result  in  serious  injury  to  personnel,  or  in  damage  to  equipment. 

A  potentially  hazardous  condition  compromises  safety  and  embodies  risk, 
but  within  reasonable  liolte  permits  continued  use  of  the  effected 
equipment,  provided  the  operator  has  been  informed  of  the  hazard  and 
appropriate  precautions  have  been  defined  and  distributed  to  the  user. 
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(c)  To  c»et  signr: icanr  contractual  requirements  (e.g., 

■  her.  leadtine  will  necessitate  slipping  approved  production,  activation, 
jr  construction  schedules,  if  the  changes  were  not  incorporated)  . 

(d)  To  effect  an  interface  change  which,  if  delayed, 

-ould  cause  schedule  slippage  or  cost  increase. 

(e)  To  effect,  through  value  engineering  or  other  cost 
reduction  efforts,  net  life  cycle  savings  to  the  Government  of  more  than 
$100,0G0.00,  where  expedited  processing  of  the  change  will  be  a  major 
factor  in  realizing  these  lower  costs. 

(3)  P.outine .  This  priority  shall  be  assigned  to  proposed  charges 
then  "emergency"  or  "urgent"  is  not  applicable.  Replies  to  routine  proposed 
changes  shall  be  made  within  forty-five  (45)  calendar  days  of  proposal  receipt. 

e.  Emergency  Procedures.  In  the  event  that  a  proposed  change  is 
determined  to  be  of  an  emergency  nature  by  the  PM/AM  or  the  SCR£  Chairman 
in  accordance  with  the  definitions  of  paragraph  5d(l),  either  cay,  at  their 
discretion,  call  an  emergency  SCR3  meeting  to  provide  immediate  processing 
of  the  change  request.  These  meetings  may  be  conducted  via  phone  or  message 
in  order  to  facilitate  rapid  handling  of  the  request.  If  an  immediate  fix 
cannot  be  generated  appropriate  steps  will  be  taken  to  ensure  that  lives  are 
not  endangered  or  national  security  jeopardized.  These  steps  may  include 
iircrafc  grounding,  non-use  of  certain  equipments  and  the  like-  All  such 
emergency  procedures  shall  result  in  a  software  Engineering  Change  Proposal 
in  accordance  with  UAVA1P.INST  4130.1. 

f.  Urzent/P.outine  Procedures 

(1)  If  the  proposed  change  results  from  a  program  malfunction, 
cognizant  user  personnel  should  attempt  to  duplicate  the  malfunction  to 
eliminate  the  possibility  that  the  malfunction  was  caused  by  operator 
error.  If  the  malfunction  is  substantiated,  a  proposed  change  should  be 
submitted  concurrently  to  the  SSA  and  the  SCP.B.  If  the  proposed  change 
is  for  codification  to  an  existing  software  program  or  a  request  for  a 

new  program  to  provide  better  service  to  the  user,  cognizant  user  personnel 
should  review  the  proposed  change  and  evaluate  its  merits  prior  to  submission 
to  the  SC?3. 

(2)  Upon  receipt  of  a  proposed  change,  the  SSA  shall  accomplish  a 
preliminary  review  and  evaluation  of  the  merits  of  the  proposal.  All  proposed 
charges  submitted  to  the  SSA  shall  be  analyzed  by  the  SSA  with  assistance  as 
required  from  ocher  SCR3  members  and  presented  for  consideration  to  the  SCP.B. 
Proposed  changes  cay  be  returned  to  Che  originator  for  revision  or  additional 
information  before  action  is  taken.  Liaison  between  proposed  change  originators 
and  the  SSA  is  encouraged  to  preclude  unnecessary  submittals.  If  a  proposed 
charge  is  determined  to  have  merit,  Che  SCP.3  Secretariat  will  provide  copies 

to  the  co'^r.izanc  SCP3  members  for  review  and  comment.  Concurrently,  the  SSA 
will  determine  the  scope  of  che  requested  change,  ics  impact,  as  well  as  the 
cos c  of  implementing  the  change.  The  SSA  will  report  these  findings  co  the 
SCP.3  at  its  regular  session. 
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(3)  At  meetings  of  the  SCRB,  proposed  changes  uill  be  reviewed 
and  evaluated.  Factors  such  as  performance  guarantees,  ground  support 
equipment  interfaces ,  other  platfors  interfaces,  training  equipment, 
implementation  cost  and  value  engineering  shall  be  considered.  The  SCRB 
Chairman  will  decide,  based  on  the  findings  of  the  SCRB,  which  proposed 
changes  will  be  recommended  by  the  SCRB.  A  written  synopsis  of  matters 
considered  and  recommendations  shall  be  prepared  and  submitted  to  the  PM /AM. 

(4)  The  SCRB  Chairman  vill  coordinate  with  the  PM /Ail  to  decide 
which  proposed  changes  will  be  implemented .  The  PM/AM  is  the  final  authority 

in  the  implementation  of  software  changes.  Factors  such  as  budgetary  constraints 
system  needs,  implementation,  test  schedule,  fleet  release  schedule,  other 
system  priorities,  and  impact  on  interfacing  systems  will  determine  which 
software'  changes  are  implemented. 

(5)  Unless  previously  designated  by  higher  authority,  the  SCRB 
Chairman  will  be  responsible  for  recommending  to  the  PM/AM  the  activity(s) 
responsible  for  developing  and  verifying  the  software  version  package, 
producing  the  system  tapes  and  documentation,  and  distributing  these 
items  to  the  fleet. 

(6)  All  software  changes  resulting  from  SCRB  actions  and  resulting 
in  a  scheduled  fleet  release  update  program  shall  be  processed  by  a  software 
Engineering  Change  Proposal  by  the  SCRB  Chairman  in  accordance  with  NAVAIRINST 
4130.1. 

6.  Recommendations  of  a  SCRB.  Recommendations  of  the  Board  must  be  in 
accordance  with  the  facts;  with  all  applicable  laws,  regulations,  policies 
and  procedures;  and  must  be  in  the  best  overall  interests  of  NAVATR. 

Enclosure  (2)  provides  a  list  of  documents  to  be  utilized  by  a  SCRB  as 
guidance  to  the  extent  that  their  contents  apply  to  the  requirements  and 
operations  of  the  particular  system  SCRB. 
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LIST  OF  SCRB  GUIDANCE  DOCUMENTS 

The  following  list  of  documents  shall  be  utilized  by  the  SCRB  as 
guidance  resources  to  the  extent  that  their  contents  apply  to  the  requirements 
and  operations  of  the  particular  system  SCRB. 


STANDARDS 

MIL- STD- 4 80 

Configuration  Control  -  Engineering  Changes, 
Deviations  and  Naivers 

MIL- STD-482 

Configuration  Status  Accounting  Data  Elements 
and  Related  Features 

MIL- STD- 4 83 

Configuration  Management  Practices  for  Systems, 
Equipment,  Munitions,  and  Computer  Programs 

M.IL-STD-490 

Specification  Practices 

MIL-STD-680 

Contractor  Standardization  Plans  and  Management 

MIL-STD-3S2 

System  Safety  Program  for  Systems  and  Associated 
Subsystems  and  Equipment,  Requirements  for 

MIL-STD-1521 

Technical  Reviews  and  Audits  for  Systems, 
Equipment,  and  Computer  Programs 

SPECIFICATIONS 
MIL-Q-9858 
MIL- S- 83490 
VS-8506 

INSTRUCTIONS 

SECNAVINST  3560.1  Tactical  Digital  Systems  Documentation  Standards 

SECNAVINST  5233. 1A  Department  of  the  Navy  Automatic  Data  Systems 

Documentation  Standards 

CPNAVIN3T  3500. 27B  Construction  and  control  of  digital  processor 

programs  for  the  Navy  Combat  Direction  Systems 

G?:;aVI::sT  1j790.2A  Naval  Aviation  Maintenance  Program 

NAVMATIKST  3960. 6a  Test  and  Evaluation 


Quality  Program  Requirements 

Specifications,  Types  and  Forms 

Requirements  for  Digital  Computer  Program 
Documentation  (Superseded  by  SECNAVINST  3560.1) 
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kavmatikst  I130.LA 

KAVMATIKST  1130.2A 

KAVMATIKST  1*130. 3A 

KAVMATII.'ST  5200 . 27 A 
KAVAIRIKST  3960.2 

KAVAIRIKST  U130.1 
KAVAIPIKST  l200.ll;. 

KAVAIRIKST  1*275-33 

KAVAIRIKST  521 5- £3 
KAVAIRIKST  5230. 3A 

KAVAIRIKST  5230.1* 

KAVAIRIKST  5230.5 
KAVAIRIKST  5UOO.ll* A 


Department  cf  Defense  Cor.figuret. 


on  Management 


Con.fi gurati or.  1'a.nejeoen t  of  Computer  Software 
Associated  with  Tactical  Digital  Systems  and 
Other  Technical  Computer  Systems  develooed  bv 
or  for  the  Kaval  Material  Command 


Standard  Combat  System  Automatic  Data  Processing 
Hardware  and  Software;  point  Configuration  Manage¬ 
ment  of 


Transfer  of  Kavv  Tactical  Digital  System  Software 
responsibility ;  procedures  for 

Test  and  Evaluation  Master  Plans  policies  and 
procedures  concerning  the  preparation,  processing, 
and  approval 

KAVAIRSYSCOM  Configuration  Management  Manual 

Policy  and  guidelines  for  procurement  of  data 
and  specific  acquisition  of  unlimited  rights  in 
technical  data 

Configuration  Control ,  KIL-STD-U20  and  KIL-STD-U81 
implementation  of 

The  KAVAIR  Technical  Directive  System 

Standard  specification  for  weapon  systems 
related  digital,  processor  programming 
documentation 


Responsibility  for  the ■ coordination  and  management 
of  weapon  system  tactical  digital  processors 
and  related  software 


Responsibility  and  requirements  for  preparation 
of  Software  Life  Cycle  Management  Plans  (SLC.M?) 

Policies  and  procedures  for  the  transfer  of 
engineering  cognizance  of  and  production 
support  responsibilities  for  service  equipment 
to  Kavy  Field  Activities 
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TADSTAND  A 


“STANDARD  DEFINITIONS  FOR  EMBEDDED  COMPUTER  RESOURCES 

IN  TACTICAL  DIGITAL  SYSTEMS" 

ABSTRACT 


•  Establishes  standard  definitions  for  embedded  computer  resources  (ECR)  in  tactical 
digital  systems. 


DEPARTMENT  OF  THE  NAVY 
HEADQUARTERS  NAVAL  MATERIAL  COMMAND 
WASHINGTON.  D  C.  20300 


IN  MPIV  *EFt*  to 

08Y/DCR 
Ser  230 
T-9 

2  July  1980 


TACTICAL  DIGITAL  8TAHDAID  (TAD STAMP)  A 


From:  Chief  of  Naval  Material 


Subjs  Standard  Definitions  for  Eabedded  Coaputer  Resources  in  Tactical 
Digital  Systeaa 


Ref: 


(a)  NAVMATINST  5430.60  of  10  July  1978  (with  effective  changes); 
Headquarters  Naval  Material  Coaaand  Organization  Manual 

(b)  CNM  ltr  09Y/CFH  Ser  113  of  6  April  1972;  Standard  Definition  of 
Tactical  Digital  Systeaa  (TAD STAND  4) 

(c)  CNM  ltr  09Y/CTH  Ser  148  of  5  June  1972;  Combat  System  Design* 
Raploying  Multiple  AN/UYK-7  Processors  (TAD STAND  6) 

(d)  DoD  Directive  5000.29  of  26  April  1976;  Management  of  Coaputer 
Resources  in  Major  Defense  Systeas 

(e)  SKCKAVINST  5200.32  of  11  June  1979;  Mangeaent  of  Eabedded  Coaputer 
Resources  in  Department  of  the  Navy  Systems 

(f)  OPNAVIHST  C3501.2R  of  12  April  1979;  Naval  Warfare  Mission  Areas 
and  Required  Operational  Capabilitias/Projected  Operational 
Environment  Statements 

(g)  OPNAVIHST  4720. 9D  of  23  August  1974;  Approval  of  Systems  and 
Equipment  for  Service  Qae 

(h)  MIL-8TD- 1679  (Navy)  of  1  December  1978;  Weapon  System  Software 
Development 


1.  Purpoee.  In  accordance  with  reference  (a),  this  TADSTAND  establishes 
stands^  definitions  for  eabedded  computer  resources  (ECR)  in  tactical  digital 
systeaa  under  the  cognisance  of  the  Naval  Material  Coamand.  This  TADSTAND 
supersedes  reference  (b). 


2.  Cance Hat ion.  Effective  this  date,  references  (b)  end  (c)  are  cancelled. 

3.  Applicability.  This  TADSTAND  applies  to  all  organisational  elements 
within  the  Naval  Material  Command.  The  definitions  below  are  the  standard 
interpretations  of  terms  to  be  applied  to  ECR  in  TDS  within  the  Navy. 


4.  Background. 

a.  Reference  (d),  as  implemented  by  reference  (e)y  establishes  DoD 
policy  for  the  management  and  control  of  computer  resources  during  the 
development,  acquisition,  deployment,  and  support  of  major  Defense  systeas . 
These  policies  are  applicable  to  all  Defense  systems  except  general  purpose, 
comaerciallyavailable  ADP  systems  that  are  subject  to  other  regulations. 
Reference  (e)  further  states,  "Navy  standard  eabedded  computer  resources  will 
be  utilised  in  systems,  except  in  those  eases  where  standards  are  demonstrated 
to  be  not  cost-effective  or  not  technically  practicable  over  the  life  of  the 
system.** 
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b.  Reference  (a)  assigns  MAT  08Y,  the  Tactical  Embedded  Computer  Program 
Office  (TECPO) ,  the  responsibility  for  designating  standard  tactical  embedded 
computers,  digital  processors,  digital  peripherals,  interface  standards, 
programming  languages,  support  software,  documentation,  acquisition  policy, 
and  configuration  control  procedures.  These  standards  are  to  be  promulgated 
in  the  fora  of  tactical  digital  standards  (TADSTANDS) .  To  ensure  that  each 
TADSTAND  is  consistent  in  specifying  policy  concerning  ECR,  this  TADSTAND 
provides  the  standard  definitions  of  terms  used  in  all  other  TADSTANDS . 

5.  Definitions. 

a.  Tactical  Digital  Systems,  in  consonance  with  reference  (e),  are  those 
tactical  weapons,  communication,  cowand  and  control,  and  intelligence  systems 
and  subsystems  that  employ  digital  computers  and  directly  support  military 
operations  in  the  following  missions  areas  (as  defined  by  reference  (f)): 

(1)  Anti-Air  Warfare 

(2)  Antisubmarine  Warfare 

(3)  Antisurface  Warfare 

(4)  Strike  Warfare 

(5)  Amphibious  Warfare 

(6)  Mine  Warfare 

(7)  Special  Warfare 

(8)  Mobility  (MOB  1  through  MOB  11) 

(9)  Commend  and  Control  and  Communications 

(10)  Intelligence 

(11)  Electronic  Warfare 

(12)  Noncombat  Operations  (NCO  2-6,  NCO  9,  NCO  18,  and  MCO  20) 

The  surface  ship,  submarine,  and  aircraft  systams  and  subsystems  included  in 
this  definition  are: 

Combat  Direction  System  (including  data  processing,  display,  and 
data  links) 


Missile  Fire  Control 
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Gun  Fire  Control 

Underwater  Battery  Fire  Control 

Underwater  Fire  Control 

Weapon  Delivery  (including  bombs,  torpedoes,  and  depth  charges) 

Electronic  Warfare  (including  signal  processing,  identification, 
and  prediction) 

Sensor  (including  beam  forming  and  signal  processing  of  radar  video, 
beacon  video,  laser,  infrared,  and  television  signals) 

Sonar  (including  beam  forming,  accoustic  signal  processing, 
identification,  and  prediction) 

Communications  (including  automated  message  processing  and 
distribution,  frequency  prediction,  and  hardware  resources  management) 

Sonobuoy  (including  deployment,  operation,  accoustic  signal 
processing,  identification,  and  prediction) 

Navigation 

Intelligence  (including  collection,  processing,  and  evaluation  of 
information) 

b.  Applications  Software  consists  of  the  computer  oof tware/f irmware  and 
associated  data  that  implement  the  operational  capabilities  of  tactical 
digital  systems.  Examples  include  target  tracking,  nsvigaton,  and  avionics 
programs . 

c.  Embedded  Computer  (EC)  is  a  digital  computer  or  processor  that  is  an 
integral  component,  from  the  design,  procurement,  and  operations  point  of 
view,  of  any  tactical  digital  system.  This  definition  includes  microcomputer , 
microprocessor,  etc. 

d.  Embedded  Computer  Resources  (ECR)  are  the  totality  of  operational  and 
support  software/ firmware;  embedded  computers;  data  storage  and  display 
devices;  interface  standards;  progressing  languages;  support  facilities 
ashore;  training  facilities;  training  support  personnel;  and  personnel  whose 
primary  specialised  educational  experience  and/or  training  is  directed  toward 
operation  or  maintenance  of  embedded  computers.  Specifically  included  are 
programmable  calculators  (PROCALS)  that  are  electrically  interfaced  to 
tactical  digital  systems. 
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e.  Hardware  Intensive  Application  is  one  in  which  the  function(s)  is/are 
fixed  and  hence  the  computer  program,  after  development  and  test,  is  not 
expected  to  be  changed  for  the  lifetime  of  the  system  or  subsystem  in  which 
the  computer  is  embedded. 

f.  Low  Level  Code  is  a  sequence  of  machine-oriented  source  statements 
that  implements  some  desired  function  or  procedure.  These  code  sequences  are 
made  up  of  source  statements  from  "Assembly"  languages,  "Machine"  languages, 
the  CMS-2  "Direct"  code  feature,  etc. 

g.  Main  Memory  is  that  component  of  an  EC  from  which  stored  programs  are 
executed  and  within  which  data,  manipulated  by  such  programs  or  involved  in 
input/output  operations,  is  stored. 

h.  Major  Upgrade,  as  it  applies  to  a  specific  system,  is  the  redesign  or 
substantial  addition  of  hardware,  the  re-writing  of  more  than  half  the 
software,  the  re-design  of  the  software  architecture,  or  the  substantial 
addition  of  new  software  functions.  If  an  operational  evaluation,  operational 
functional  checkout,  or  equivalent  is  required,  the  system  upgrade  is 
considered  major. 

i.  Planned  Standard  is  a  designation  assigned  by  the  Chief  of  Haval 
Material  to  selected  ECR  under  developement,  evaluation,  or  consideration  with 
the  intent  to  designate  them  as  standards,  normally,  approval  for  service  use 
(ASU)  is  required  for  hardware  in  this  category  prior  to  designation  as 
standard.  This  definition  is  in  consonance  with  reference  (g). 

j.  Programming  Laaguage  is  a  language  in  which  computer  program 
partitioning  constructs,  symbolic  and  numerical  algorithms,  and  associated 
data  structures  are  expressed  such  that  they  may  be  aMchine  translated  into 
executable  instructions  (under  translation  and  loading  directives  which  may 
also  be  included  in  the  programning  language  syntax). 

k.  Prograting  Language  Preprocessor  is  a  computer  program  that 
transforms  input  source  text  into  source  text  suitable  for  direct  processing 
by  a  specific  compiler.  Specific  functions  include  host-dependencies  removal, 
macro  expansion,  string  substitution,  file  insertion,  pre-compilation 
calculations,  and  conditional  compilation. 

l.  Pseudo  Code  is  a  natural  language  abstract  description  of  computer 
programning  algorithms  and  associated  data  structures.  Pseudo  code  is  often 
used  as  a  progressing  design  language  in  computer  software  development. 

m.  Secondary  Storage  is  that  component  of  an  EC  that  is  used  as  an 
auxiliary  to  main  memory.  Typical  types  of  secondary  storage  are  bulk  store, 
magnetic  tapes,  disks,  and  drums. 
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n.  Standard  is  a  designation  assigned  by  the  Chief  of  Naval  Material  to 
selected  ECR  that  are  approved  for  service  use  or  otherwise  authorized  for 
use.  The  minimum  criteria  for  designating  selected  ECR  as  standard  are 
assignment  to  a  designated  configuration  control  board,  assignment  to  a 
designated  development  or  maintenance  activity  for  life  cycle  support,  and 
in-service  use  in  at  least  one  tactical  digital  system.  This  definition  is  in 
consonance  with  reference  (g). 

o.  Support  Software  consists  of  the  computer  software/ firmware  and 
associated  data  that  are  the  means  by  which  software/ firmware  for  tactical 
digital  systems  is  developed,  tested,  executed,  and  maintained.  Such  software 
includes: 


(1)  Requirements  and  specification  analyzers 

(2)  Text  editors,  compilers,  interpreters,  assemblers,  linkage 
editors,  builders,  librarians,  loaders,  utilities,  and  operating  systems. 

(3)  Test  case  generators,  symbolic  execution  analyzers,  and  other 
debugging  programs. 

(4)  Stimulation  and  simulation  programs 

(5)  Data  extraction,  insertion,  and  reduction  programs 

(6)  Programs  used  for  data  base  management,  management  control, 
configuration  management,  and  documentation  generation  and  control. 

Trainer,  test,  and  maintenance  software  are  not  considered  support  software  in 
this  definition  and  are  separately  defined  in  reference  (h). 

6.  Deviations.  The  purpose  of  this  TADSTAND  is  to  ensure  consistent  meaning 
and  usage  of  terms  related  to  ECR  in  other  TADSTANDs  and  in  documentation 
associated  with  tactical  digital  systems.  Therefore,  it  is  inappropriate  to 
request  deviation  from  this  TADSTAND. 

7.  Inquiries.  Inquiries  concerning  the  application  or  intrepretation  of  this 
and  other  TADSTANDs  should  be  addressed  to: 

Chief  of  Naval  Material  (Attn:  MAT  08Y ) 

Navy  Department 
Washington,  D.  C.  20360 

Phone:  Autovon  222-3966;  Commercial  (202)692-3966 
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TADSTAND  B 

"STANDARD  EMBEDDED  COMPUTERS.  COMPUTER  PERIPHERALS. 
AND  INPUT/OUTPUT  INTERFACES" 

ABSTRACT 


•  Established  standard  embedded  computers,  computer  peripherals  and  input/output 
(I/O)  interfaces. 

•  Included  are  both  standards  and  planned  standards. 
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TACTICAL  DIGITAL  STANDARD  B  (Revision  1) 


From:  Chief  of  Naval  Material 


Subj:  Standard  Embedded  Computers,  Displays,  Peripherals,  and  Input/Output 
Interfaces 


Ref: 


(a)  NAVMATINST  5430.60  of  10  July  1978  (with  effective  changes); 
Headquarters  Naval  Material  Command  Organization  Manual 

(b)  CNM  ltr  08Y/BWS  Ser  231  of  2  July  1980;  Standard  Embedded 
Computers,  Computer  Peripherals,  and  Input/Output  Interfaces 
(TADSTAND  B) 

(c)  CNM  ltr  08Y/DCR  Ser  230  of  2  July  1980;  Standard  Definitions  for 
Tactical  Embedded  Computer  Resources  (TADSTAND  A) 

(d)  DoD  Directive  5000.29  of  26  April  1976;  Management  of  Computer 
Resources  in  Major  Defense  Systems 

(e)  SECNAVINST  5200.32  of  11  June  1979;  Management  of  Embedded 
Computer  Resources  in  Department  of  the  Navy  Systems 

(f)  NAVMATINST  4130. 1A  of  1  July  1974;  Configuration  Management 

( g)  MIL-STD-882A  of  28  June  1977;  System  Safety  Program  Requirements 


1.  Purpose.  In  accordance  with  reference  (a),  this  TADSTAND  reissues 
reference  (b)  and  is  promulgated  to  establish  standard  embedded  computers, 
displays,  peripherals,  and  input/output  (I/O)  interfaces  for  use  within  the 
Naval  Material  Command. 


2.  Cancellation.  Reference  (b)  is  hereby  cancelled. 

3.  Definitions.  The  following  terms  are  defined  in  reference  (c): 

a.  Embedded  Computer  (EC) 

b.  Embedded  Computer  Resources  (ECR) 

c.  Main  Memory 

d.  Major  Upgrade 

e.  Planned  Standard 

f.  Standard 

h.  Tactical  Digital  Systems 
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4.  App 1 i cab i 1 ity 

a.  This  TADSTAND  applies  to  all  tactical  digital  systems  under  the 
cognizance  of  the  Chief  of  Naval  Material  (CHNAVMAT).  This  TADSTAND  also 
applies  to  development  programs  under  the  cognizance  of  CHNAVMAT  that  are 
ultimately  intended  to  be  employed  as  tactical  digital  systems  or  as 
components  thereof.  This  TADSTAND  applies  to  all  phases  of  system 
acquisition,  including  initial  concept  formulation  and  requirements 
definition,  design,  development,  installation,  production,  and 

post- development  support  throughout  the  service  life  of  the  system  regardless 
of  funding  or  acquisition  category. 

b.  The  provisions  of  this  TADSTAND  are  not  to  be  applied  retroactively 
to  systems  for  which  hardware  (computer  or  peripheral)  or  I/O  interface 
commitments  have  already  been  made.  However,  all  hardware  commitments  made 
prior  to  the  effective  date  of  this  TADSTAND  must  have  been  in  compliance  with 
superseded  reference  (b).  Compliance  includes  use  of  previously  designated 
standards  or  a  CHNAVMAT  approved  waiver. 

c.  Excluded  from  the  requirements  of  this  TADSTAND  is  the  use  of 
processors  or  computers  that  are  wholly  contained  on  a  single  integrated 
circuit,  that  have  a  data  path  of  eight  (8)  bits  or  less  to  main  memory  and 
that  have  a  maximum  addressability  of  65,536  or  fewer  memory  locations. 

5.  Background 

a.  Reference  (d),  as  implemented  by  reference  (e),  establishes  DoD 
policy  for  the  management  and  control  of  computer  resources  during  the 
development,  acquisition,  deployment,  and  support  of  major  defense  systems. 
These  policies  are  applicable  to  all  defense  systems  except  general  purpose, 
commercially-avail able  ADP  systems  that  are  subject  to  other  regulations. 
Reference  (e)  further  states,  "Navy  standard  embedded  computer  resources  will 
be  utilized  in  systems,  except  in  those  cases  where  standards  are  demonstrated 
to  be  not  cost-effective  or  not  technically  practicable  over  the  life  of  the 
system." 

b.  Standard  Embedded  Computer  Resources  (ECR)  have  been  successfully 
utilized  in  a  wide  variety  of  tactical  digital  systems  in  aircraft,  ships  and 
submarines.  Applications  include  fire  control;  signal  processing;  navigation; 
and  command,  control  and  communications  systems. 

c.  The  rationale  for  the  requirement  to  use  standard  ECR  in  tactical 
digital  systems  is  based  on  the  need  to  stem  ECR  proliferation,  achieve  an 
acceptable  level  of  supportabil ity,  and  reduce  costs  over  the  life  cycle  of 
systems.  Standardization,  together  with  sound  life  cycle  configuration 
management  and  logistics  support  practices,  will  significantly  improve  the 
reliability  and  maintainability  of  tactical  digital  systems  while  minimizing 
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ECR  related  costs.  Furthermore,  standard  ECR  will  reduce  both  cost  and 
schedule  risks  in  development  and  acquisition  of  new  tactical  digital  systems. 

6*  Policy.  Only  those  Navy  standard  and/or  planned  standard  embedded 
computers,  displays,  peripherals,  and  I/O  interfaces  specified  in  paragraph  7 
of  this  TADSTAND  shall  be  used  in  initial  development  and  for  each  major 
upgrade  of  applicable  systems. 

7.  Standards  and  Planned  Standards.  Each  equipment  or  I/O  interface  listed 


below  is  a  standard  or  planned  standard  for  those  environments  for  which  it  is 
qualified  or  planned  to  be  qualified.  Except  for  interfaces  internal  to  a 
computer,  all  computer  and  peripheral  interconnections  in  tactical  digital 
systems  shall  be  standard  I/O  interfaces. 

a.  The  following  are  designated  as  standard  embedded  computers, 
displays,  and  peripheral  equipment: 


Nomenclature 


Program  and  Acquisition  Office 


AN/AYK-14,  computer 

PMA-533  (NAVAIR) 

AN/UYK-7,  computer 

PMS-408  (NAVSEA) 

AN/UYK-20,  computer 

PMS-408  (NAVSEA) 

AN/UYS-1,  signal  processor 

PMA-264  (NAVAIR) 

AN/dYA-4,  display 

PMS-408  (NAVSEA) 

AN/UYQ-21,  display 

PMS-408  (NAVSEA) 

AN/UYH-2,  disk 

PMS-408  (NAVSEA) 

AN/UYH-3,  disk 

PMS-408  (NAVSEA) 

RD-358/UYK, 
magnetic  tape  unit 

PMS-408  (NAVSEA) 

AN/USH-26,  cartridge 
magnetic  tape  unit 

PMS-408  (NAVSEA) 

AN/USQ-69,  alphanumeric 
display 

PMS-408  (NAVSEA) 

0J-326/UYK,  submarine  display 

PMS-408  (NAVSEA) 

IP-1181,  submarine  display 

PMS-408  (NAVSEA) 
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Note: 

(1)  The  AN/AYK-14  was  developed  as  a  family  of  baselined  shop 
replaceable  assemblies  (SRA)  that  may  be  configured  into  weapon  replaceable 
assemblies  (WRA)  to  meet  user  embedded  computer  requirements.  The  SRAs  are 
also  available  for  direct  embedding  in  user  developed  WRAs. 

b.  The  following  are  designated  as  planned  standard  computers: 

Nomenclature  Program  and  Acquisition  Office 


AN/UYK-44,  computer  PMS-408  (NAVSEA) 
AN/UYK-43,  computer  PMS-408  (NAVSEA) 
AN/UYS-2,  signal  processor  PMS-408  (NAVSEA) 


Notes: 

(1)  The  AN/UYK-43,  Navy  Embedded  Computer  System  (NECS),  is  being 
developed  as  a  family  of  highly  reliable,  high  performance  successors  to  the 
AN/UYK-7.  The  AN/UYK-43  will  be  software  compatible  with  the  AN/UYK-7. 

(2)  The  AN/UYK-44  Militarized  Reconfigurable  Processor  (MRP)  is  being 
developed  as  a  highly  reliable,  low  cost,  power,  size,  and  weight  processor 
for  direct  embedding  in  equipment.  A  packaged,  stand-alone  Militarized 
Reconfigurable  Computer  (MRC)  version  of  the  AN/UYK-44  is  also  being 
developed.  The  AN/UYK-44  MRP  and  MRC  will  be  software  compatible  with  the 
AN/UYK-20. 

(3)  The  AN/UYS-2  Enhanced  Modular  Signal  Processor  (EMSP)  is  being 
developed  as  a  highly  reliable,  high  performance  successor  to  the  AN/UYS-1  for 
signal  processing  applications. 

c.  The  following  are  designated  as  standard  I/O  interfaces: 


Nomenclature 


Principal  Application 


Cognizant  Office 


MIL -STD-1397 

Surface  and  Airborne 
Tactical  Digital  Systems 

PMS-408  (NAVSEA) 

MIL-STD-188-114 

Tactical  Digital 

Cormuni cations  Systems 
(synchronous  and 

PME-110/231  (NAVELEX) 

asynchronous) 
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Electronic  Industries 
Association  Standard 
RS-232-C 

Tactical  Digital  Systems 

PME-110/231  (NAVELEX) 

MIL-STD-1553A  &  B 

Airborne  Serial 

Multiplex  Bus 

AIR-533 

(NAVAIR) 

MIL-A-85232 

Proteus  Digital  Channel 

PMA-264 

(NAVAIR) 

NAT-STD-4153 

NATO  STANAG 

Surface  Tactical  Digital 
Systems  (10  MHZ  serial 
asynchronous) 

SEA-61X 

(NAVSEA) 

NAT -STD-4156 

Surface  Interior 

SEA-61X 

(NAVSEA) 

NATO  STANAG  Electrical  &  Electronic 

Communication  Systems 
(1-3  MHZ  serial  synchronous) 

8.  Configuration  Management.  Strict  configuration  management  and  control  of 
standard  ECR  will  be  exercised  by  the  respective  development  offices  or 
follow-on  cognizant  acquisition,  maintenance,  or  support  offices  under  the 
guidance  of  established  Configuration  Control  Boards  (CCBs)  in  accordance  with 
reference  (f).  Such  offices  will  maintain  an  effective  failure  feedback 
system  for  problem  identification  and  prioritized  corrective  action  in  the 
form  of  Engineering  Change  Proposals  (ECPs).  Reference  (f)  requires  that 
prior  to  or  concurrent  with  ECP  approval,  the  impact  upon  integrated  logistic 
support,  as  well  as  the  overall  estimated  cost  impact,  be  considered. 

Reference  (f)  further  requires  that  funding  authorization  be  issued  for  the 
scheduled  implementation  of  a  change  when  an  ECP  is  approved.  For  cases  in 
which  total  funding  authorizations  to  complete  the  ECP  in  all  equipments  and 
provide  the  necessary  integrated  logistic  support  cannot  be  made  concurrent 
with  ECP  approval,  the  ECP  must  be  reconsidered  for  reduction  in  scope  or 
disapproval.  For  ECR  under  development,  the  development  office  will  ensure 
that  appropriate  configuration  management  and  control  procedures  are 
established  under  a  cognizant  CCB  in  accordance  with  reference  (f). 

9.  Waivers 


a.  It  is  recognized  that,  in  some  cases,  strict  adherence  to  this 
TADSTAND  could  be  technically  infeasible,  economically  prohibitive,  or 
operationally  impracticable.  When  an  exception  to  this  TADSTAND  is  considered 
to  be  in  the  best  interests  of  the  Navy,  a  TADSTAND  waiver  may  be  granted  by 
the  CHNAVMAT.  An  approved  waiver  will  be  effective  only  until  the  next  major 
upgrade  of  the  system  concerned.  When  a  major  upgrade  is  planned,  a  new 
waiver  request,  if  warranted,  must  be  submitted. 

b.  Waiver  requests  related  to  computer,  display,  peripheral  equipment, 
or  I/O  standards  shall  be  submitted  to  CHNAVMAT  (Attn:  MAT  08Y)  via  the 
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SYSCOM  responsible  for  the  development  of  the  system  for  which  the  exception 
is  being  requested.  Each  request  will  be  considered  on  a  case-by-case  basis. 
In  order  to  preclude  implied  waivers,  a  waiver  is  required  for  each  specific 
element  of  a  developing  system  or  subsystem  for  which  an  exception  is  deemed 
necessary.  An  approved  waiver  from  this  TADSTAND  does  not  imply  waiver  from 
the  other  TADSTANDS.  To  minimize  the  fiscal  or  schedule  impact  of  this 
TADSTAND  on  projects,  cognizant  agencies  are  enjoined  to  conduct  liaison  with 
the  CHNAVMAT  (MAT  08Y)  prior  to  conmitment  to  a  specific  course  of  action  that 
could  potentially  result  in  a  request  for  a  TADSTAND  waiver. 

c.  When  non-standard  equipments  are  directed  by  higher  authority,  a 
CHNAVMAT  approved  TADSTAND  waiver  is  still  required.  Total  life  cycle  costs, 
including  logistics  and  software  support,  will  be  a  critical  factor  in  the 
consideration  of  such  a  waiver  request.  Based  on  the  justification  provided 
in  the  waiver  request,  CHNAVMAT  will  make  a  recommendation  to  higher  authority 
concerning  directed  use  of  the  non-standard  versus  standard  equipments  or 
grant  the  waiver. 

rj.  A  waiver  request  shall  include  the  following  information: 

(1)  Name,  function(s),  and  operating  description  of  system  for 
which  waiver  is  requested. 

(2)  Platform(s)  on  which  system  is  to  be  installed. 

(3)  All  embedded  computer  resources  (computers,  displays, 
peripherals,  and  I/O  interfaces)  and  functions  of  each  as  well  as  system  block 
diagram(s)  depicting  the  interconnection  of  these  resources. 

(4)  Storage  and  I/O  requirements,  and  throughput  parameters. 

(5)  Software  constraints  (e.g.,  timing  and  space). 

(6)  Environmental  requirements  and/or  constraints  on  the  embedded 
computer  resources. 

(7)  Reasons  why  standards  and/or  planned  standards  cannot  be  used, 
including  supporting  rationale. 

(8)  Proposed  substitute (s),  together  with  supporting  rationale, 
showing  that  the  proposed  substitute(s)  meet  the  special  requirements. 

(9)  Data  (e.g.,  costs,  performance,  schedule)  on  using  the  proposed 
substitute(s)  compared  with  using  required  standards  and/or  planned 
standards.  The  following  areas  shall  be  addressed: 


(a)  Acquisition  (hardware,  software,  and  firmware). 
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(b)  Integrated  Logistic  Support  (ILS)  data  for  life  of  the 
system  (e.g.,  training,  spare  parts,  documentation,  life  cycle  maintenance). 

(c)  Testing. 

(10)  Reliability  and  maintainability  requirements  and  demonstrated 
tests  and  operational  data. 

(11)  Safety  in  compliance  with  reference  (g). 

(12)  Other  testing  conducted  or  to  be  conducted. 

(13)  Data  as  in  item  (9)  for  any  device(s)  required  to  interface 
the  proposed  non-standard  digital  processing  hardware  with  other  hardware 
installed  in  the  same  platform. 

(14)  Data  as  in  item  (9)  for  alternative  design(s)  using  required 
standards  and/or  planned  standards. 

10.  Inquiries.  Inquiries  concerning  the  application  or  interpretation  of 
this  and  other  TADSTANDs  should  be  addressed  to: 

Chief  of  Naval  Material  (Attn:  MAT  08Y) 

Navy  Department 

Washington,  D.  C.  20360 

Phone:  Autovon  222-3966;  Commercial  (202)  692-3966 


Distribution: 

SNDL  A3  (CNO)  (OP  112,  22,  211,  224,  35,  351,  04,  55,  551,  94,  940,  941, 
942,  944,  95,  98,  982,  983,  only) 

A2A  (CNR) 

A6  (Headquarters,  U.S.  Marine  Corps)  (Codes  CCA-50  and  LMC  only) 

C4K  (CNM  PMs) 

E3A  (Lab  ONR) 

FE1  (COMNAVSECGRU) 

FF8  (Inspection  and  Survey  Board) 

FF52  (NAVTACINTEROPSUPPACT) 

FG1  (COMNAVTELCOM) 

FKA1A  (COMNAVAIRSYSCOM)  (30  copies) 
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Distribution  (continued): 

FKA1B  ( COMNAVELEXSYSCOM )  (30  copies) 

FKA1F  (COMNAVSUPSYSCOM) 

FKA1G  (COMNAVSEASYSCOM)  (30  copies) 

FKA6A  (CNM  R&D  Centers)  (3  copies  each) 

FKP1G  (NAVSHIPWPNSYSENGSTA) 

FKP14  (FLTCOMBATDIRSSACT) 

FKP15  (INTCOMBATSYSTESFAC) 

FKQ3A  ( NAVELEXSYSENGCEN) 

FKQ3B  ( NAVELEXSYSENGACTDET ) 

FKR3C  (NAVAIRTESTCEN) 

FKR4A  (PACMISTESTCEN) 

FKR5  (NAVAVIONICCEN) 

FS1  (COMNAVINTCOM) 

FT1  (CNET) 

FT73  (NAVPGSCHOL)  (Computer  Science,  Engineering,  and  Library  Depts 

only) 

26F  (OPTEVFOR) 

V12  (Development  and  Education  Command,  Marine  Corps;  MCTSSA) 

ASN ( S&L  and  RE&S)  (2  copies  each) 

NAVMAT  SP  List  2 

Defense  Systems  Management  College  (Technical  Management  Division) 
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TADSTAND  C 


"COMPUTER  PROGRAMMING  LANGUAGE  STANDARDIZATION 
POLICY  TACTICAL  DIGITAL  SYSTEMS" 

ABSTRACT 

•  Promulgates  policy  for  the  standardization  of  computer  programming  languages  used  in 
the  development,  acquisition,  deployment,  and  support  of  tactical  digital  system. 

•  Defines  when  low  level  code  may  be  used. 

•  Defines  both  approved  and  planned  approved  programming  languages. 

•  Defines  approved  programming  language  preprocessor. 


DEPARTMENT  OF  THE  NAVY 
HEADQUARTERS  NAVAL  MATERIAL  COMMAND 
WASHINGTON,  D  C.  20360 


IN  REPLY  REFER  TO 

08Y/0LM 
Ser  232 
T-9 

2  July  1980 


TACTICAL  DIGITAL  STANDARD  (TAD STAND)  C 


From:  Chief  of  Naval  Material 


Subj:  Computer  Programing  Language  Standardization  Policy  for  Tactical 
Digital  Systems 


Ref: 


(a)  NAVMATINST  5430.60  of  10  July  1978  (with  effective  changes); 
Headquarters  Naval  Material  Comand  Organization  Manual 

(b)  CNM  ltr  08Y/BWS  Ser  231  of  2  July  1980;  Standard  Embedded 
Computers,  Computer  Peripherals,  and  Input /Out put  Interfaces 
(TAD STAND  B) 

(c)  CNM  ltr  09Y/JER  Ser  130  of  29  May  1973;  Standard  Shipboard 
Tactical  Digital  Processors  and  Program  Language  (TADSTAND  1 
(Revision  D) 

(d)  CNM  ltr  08Y/DCR  Ser  230  of  2  July  1980;  Standard  Definitions  for 
Embedded  Computer  Resources  in  Tactical  Digital  Systems 
(TADSTAND  A) 

(e)  DoD  Instruction  5000.2  of  19  March  1980;  Major  System  Acquisition 
Procedures 

(f)  SECNAVINST  5230.4  of  3  May  1976;  Department  of  the  Navy  Automatic 
Data  Processing  Program 

(g)  DoD  Instruction  5000.31  of  24  November  1976;  Interim  List  of  DoD 
Approved  High  Order  Programming  Languages  (H0L)  (under  revision) 

(h)  SECNAVINST  5200.32  of  11  June  1979;  Management  of  Embedded 
Computer  Resources  in  Department  of  Navy  Systems 


1.  Purpose.  In  accordance  with  reference  (a),  this  TADSTAND  promulgates 
policy  for  the  standardization  of  computer  programming  languages  used  in  the 
development,  acquisition,  deployment,  and  support  of  tactical  digital 
systems.  This  TADSTAND,  in  conjunction  with  reference  (b),  supersedes 
reference  (c).  Reference  (b)  cancels  reference  (c). 


2.  Definitions.  The  following  terms  used  in  this  TADSTAND  are  defined  in 
reference  (d): 


a.  Applications  Software 

b.  Embedded  Computer  (EC) 

c.  Embedded  Computer  Resources  (ECR) 

d.  Hardware- Intensive  Application 


e.  Low  Level  Code 

f.  Major  Upgrade 
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g.  Planned  Standard 

h.  Programming  Language 

i.  Programing  Language  Preprocessor 

j .  Pseudo  Code 

k.  Standard 

l.  Support  Software 

m.  Tactical  Digital  Systems 
3.  Applicability. 

a.  This  TADSTAND  applies  to  all  tactical  digital  systems  under  the 
cognizance  of  the  Naval  Material  Comand.  This  TADSTAND  also  applies  to 
development  programs  under  the  cognizance  the  Naval  Material  Command  that  are 
ultimately  intended  to  be  employed  as  tactical  digital  systems  or  as 
components  thereof.  Except  as  noted  in  paragraph  3.b  below,  this  TADSTAND 
applies  to  all  phases  of  tactical  digital  system  acquisition,  including 
initial  concept  formulation  and  requirements  definition,  design,  development, 
installation,  production,  and  post-development  support  throughout  the  service 
life  of  the  system. 

b.  in  the  specific  case  of  major  system  acquisitions  that  are  based  on 
reference  (e),  the  provisions  of  this  TADSTAND  need  not  be  applied  prior  to 
the  Demonstration  and  Validation  phase.  In  these  instances,  acquisition 
managers  must  ensure  that  contractors  are  aware  that  the  provisions  of  this 
TADSTAND  will  be  applied  to  all  phases  of  the  acquisition  commencing  with  the 
Demonstration  and  Validation  phase. 

c.  Unless  otherwise  specified,  the  provisions  of  this  TADSTAND  apply 
to  the  development  of  both  applications  software  and  support  software. 

d.  Except  as  noted  in  paragraph  3 . f . ( 1 )  below,  the  provisions  of  this 
TADSTAND  apply  to  those  applications  for  which  a  waiver  has  been  granted  for 
the  use  of  a  non-standard  embedded  computer. 

e.  The  provisions  of  this  TADSTAND  are  not  to  be  applied  retroactively 
to  systems  for  which  a  language  commitment  has  already  been  made.  All 
language  commitments  made  prior  to  tbs  effective  date  of  this  TADSTAND  must 
have  been  in  compliance  with  applicable  portions  of  reference  (c).  Otherwise, 
a  waiver  request  must  be  submitted  within  90  days  from  the  effective  date  of 
this  TADSTAND.  In  those  instances  where  systems  were  in  compliance  with 
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reference  (c)  but  are  not  in  compliance  with  this  TADSTAND,  the  provisions  of 
this  TADSTAND  need  not  be  applied  until  the  next  major  upgrade  of  those 
applicable  systems. 

f.  Excluded  from  the  provisions  of  this  TADSTAND  are: 

(1)  Hardware-intensive  applications  authorized  to  use 
non-standard  microprocessors.  In  these  cases,  where  Navy  software 
modification  or  maintenance  is  not  required,  language  selection  should  be 
based  on  an  appropriate  balance  of  cost,  schedule  and  performance  trade-offs. 

(2)  Software  developed  for  use  with  automatic  data  processing 
assets  as  defined  and  administered  under  reference  (f). 

(3)  Those  special  purpose  languages  that  do  not  fall  within  the 
category  of  a  programming  language  as  used  in  this  TADSTAND  (e.g. , 
requirements  definition  languages,  design  specification  languages,  automatic 
test  languages,  job  control  languages,  and  simulation  languages). 

4.  Background. 

a.  Reference  (g)  establishes  CMS-2,  SPL/1,  and  FORTRAN  as  DoD  approved 
high  order  programming  languages  (HOLs)  and  assigns  control  of  CMS-2  and  SPL/I 
to  the  Department  of  the  Navy.  Reference  (h)  establishes  the  requirement  that 
CMS-2  and  SPL/I  be  used  to  develop  applications  software. 

b.  The  rationale  for  the  requirement  to  use  standard  HOLs  is  based  on 
improved  maintainability  and  cost  effectiveness  over  the  life  cycle  of  the 
system.  Standardization,  together  with  sound  life  cycle  management  practices, 
will  result  in  a  significant  reduction  to  the  spiraling  costs  for  developing, 
testing,  and  maintaining  tactical  digital  systems.  The  importance  of  this 
issue  is  obvious  in  view  of  the  substantial  expenditures  within  the  Navy  for 
embedded  computer  resources,  particularly  applications  software  for  tactical 
digital  systems. 

5.  Policy. 


a.  Only  those  Navy  standard  HOLs,  associated  language  implementations 
(compilers  and  their  support  systems),  and  Navy  standard  programing  language 
preprocessors  specified  in  paragraphs  6. a  and  6.b  below  will  be  used  in 
applicable  systems,  unless  a  waiver  is  obtained. 

b.  Consistent  with  the  underlying  objectives  to  achieve  life  cycle 
supportability  and  reliability  at  lowest  cost,  low  level  code  may  be  used 
without  a  waiver  in  the  following  instances: 
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(1)  Low  level  code  may  be  used  for  required  machine  oriented 
functions  where  the  programming  language  does  not  provide  high  level  support 
(e.g.,  Input/Output  instructions,  etc.) 

(2)  Low  level  code  may  be  used  for  software  functions  which 
require  special  optimizing  or  fine-tuning  in  order  to  meet  performance 
requirements,  and  that  are  not  subject  to  significant  life  cycle  modification 
(e.g.,  executives,  interrupt  handlers,  math  routines,  etc.) 

In  all  other  instances,  low  level  code  will  not  be  used,  unless  a  waiver  is 
obtained. 


c.  When  low  level  code  is  used,  with  or  without  a  waiver,  all 
documentation  for  purposes  of  maintenance  and  future  modifications  will  be 
maintained  at  the  HOL  level  (e.g.,  pseudo  code)  with  supporting  documentation 
also  at  the  low  level.  In  addition,  all  low  level  code  must  be  encapsulated 
within  Procedure  structures  that  are  capable  of  being  called  with  the  standard 
HOL  calling  mechanisms.  Acquisition  agencies  must  maintain  a  record  of  such 
usage  in  order  to  support  periodic  review  by  the  Tactical  Embedded  Computer 
Program  Office  for  the  purpose  of  determining  requirements  for  improvement  of 
the  standard  HOLs. 

6.  Approved  Navy  Standards.  Effective  this  date,  project  and  acquisition 
managers  and  other  development  and  support  activities  shall  use  the  approved 
Navy  standards  identified  below.  In  each  case  the  standard  is  defined  by  the 
most  recent  official  version  of  the  designated  document. 

a.  Programming  Languages 

(1)  CMS-2Y  CMS-2Y  Programming  Reference  Manuals,  M-5044 

and  M-5049,  FCDSSA,  San  Diego,  Ca. 

Note:  The  CMS-2Y(20)  and  CMS-2Y(642)  dialects  are  not  approved 
for  use  in  new  applicable  systems. 

(2)  CMS-2M  CMS-2M  Computer  Program  Performance 

Specification,  NAVSEA  0967  LP-598-2210 

(formerly  NAVE LEX  0967-LP-598-2210) 

(3)  SPL/I  SPL/I  Language  Reference  Manual, 

5490-163:EF:vjs,  NRL,  Washington,  D.C. 

Note:  Since  SPL/I  has  language  features  that  require  executive 
services,  the  definition  of  the  Common  Real-time  Operating  System  (CROS)  is 
considered  to  be  a  part  of  SPL/1  and  is  therefore  designated  as  an  SPL/I 
configuration  item.  CROS  is  specified  by  "Common  Real-time  Operating  System 
(CROS)  Program  Performance  Specification",  NRL,  Washington,  D.C. 
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(4)  Ada  Ada  Language  Reference  Manual 

Restriction:  The  Ada  language  is  currently  designated  as  a 
planned  Navy  standard  language.  Use  of  the  Ada  language  in  applicable  systems 
is  not  authorized  until  formally  designated  as  a  Navy  standard  language  or  an 
explicit  waiver  is  obtained. 

b .  Programming  Language  Preprocessors. 

(1)  SPL/I/CMS-2  SPL/I/CMS-2  Preprocessor  Program  Performance 

Preprocessor  Specification,  NAVSEA  0967-LP-598-2540 

c.  Other  Programming  Languages. 

(1)  FORTRAN  ANS  FORTRAN  ANSI  X3. 9-1978 

Restriction:  FORTRAN  is  not  approved  for  use  in  the  development 
of  applications  software  (vice  support  software)  unless  a  reference  (b)  waiver 
has  been  granted  for  the  use  of  a  non-standard  embedded  computer. 

7.  Deviations. 

a.  It  is  recognized  that,  in  some  cases,  strict  adherence  to  this 
TADSTAND  could  be  technically  infeasible,  economically  prohibitive,  or 
operationally  impracti cable.  When  a  deviation  is  considered  to  be  in  the  best 
interests  of  the  Navy,  a  TADSTAND  waiver  may  be  granted  by  the  Chief  of  Naval 
Material  (CNM).  An  approved  waiver  will  be  effective  only  until  the  next 
major  upgrade  of  the  system  concerned.  When  a  major  upgrade  is  planned,  a  new 
waiver  request,  if  warranted,  must  be  submitted. 

b.  Waiver  requests  shall  be  submitted  to  CNM  (Attn:  MAT  08Y)  via 
PMS-408  or  PMA-533,  as  appropriate.  Each  request  will  be  considered  on  a 
case-by-case  basis.  In  order  to  preclude  implied  waivers,  a  waiver  is 
required  for  each  specific  element  of  an  applicable  system  or  subsystem  for 
which  a  deviation  is  deemed  necessary.  In  particular,  this  TADSTAND  should  be 
reviewed  whenever  a  waiver  to  the  provisions  of  reference  (b)  is 
contemplated.  To  minimize  the  fiscal  or  schedule  impact  of  this  TADSTAND  on 
projects,  cognizant  agencies  are  enjoined  to  conduct  liaison  with  the  Chief  of 
Naval  Material  (MAT  08Y)  prior  to  commitment  to  a  specific  course  of  action 
that  could  potentially  result  in  a  request  for  a  TADSTAND  waiver. 

c.  A  waiver  request  shall  include  the  following  information: 

(1)  Name,  function(s),  and  operating  description  of  system  for 
which  waiver  is  requested. 


(2)  Platform(s)  on  which  system  is  to  be  installed. 
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(3)  All  embedded  computer  resources  (computers,  peripherals, 
displays,  I/O  interfaces,  etc.)  and  functions  of  each  as  well  as  system  block 
diagram(s)  depicting  the  interconnection  of  these  resources. 

(4)  Storage  and  I/O  requirements,  and  throughput  parameters. 

(5)  Software  constraints  (e.g.,  timing  and  space). 

(6)  Reasons  why  standards  cannot  be  used,  including  supporting 
rationale,  documentation,  etc. 

(7)  Proposed  substitute(s) ,  together  with  supporting  rationale, 
documentation,  etc.,  showing  that  the  proposed  substitute(s)  meet  the  special 
requirements. 

(8)  Data  (costs,  performance,  schedule,  etc.)  on  using  the 
proposed  substitute(s)  compared  with  using  required  standards.  The  following 
areas  shall  be  addressed: 

(a)  Acquisition  (hardware,  software,  and  firmware). 

(b)  Integrated  Logistic  Support  (ILS)  data  for  life  of  the 
system  (training,  documentation,  life  cycle  maintenance,  etc.). 

(c)  Testing. 

8.  Inquiries.  Inquiries  concerning  the  application  or  intrepretation  of  this 
and  other  TADSTANDs  should  be  addressed  to: 

Chief  of  Naval  Material  (Attn:  MAT  08Y) 

Navy  Department 

Washington,  D.  C.  20360 

Phone:  Autovon  222-3966;  Commercial  (202)  692-3966 
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Distribution: 

SNDL  A3  (CNO)  (OP  112,  22,  211,  224,  35,  351,  04,  55,  551,  94,  940,  941, 
942,  944,  95,  98,  982,  983,  only) 

A2A  (CNR)  (Codes  240  and  437  only) 

A6  (Headquarters,  D.S.  Marine  Corps)  (Codes  LMC-3  and  CCA4  only) 
C4K  (CNM  PMs) 

E3A  (Lab  ONR)  (NRL  only)  (3  copies) 

FE1  (COMNAVSECGRU) 
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further  distribution)) 

FKAlB  (COMNAVELEXSYSCOM)  (NAVELEX  00B-SESO  (200  copies  for  further 
distribution) ) 

FKA1F  (COMNAVSUPSYSCOM)  (SUP  045  only) 

FKA1G  (COMNAVSEASYSCOM)  ( SEA-06D  and  SEA-61  (1  copy  each),  PMS-408 
(200  copies  for  further  distribution)) 

FKA6A  (CNM  R&D  Centers  (3  copies  each)) 

FKPlG  (NAVSHIPWPNSYSENGSTA) 

FKP14  (FLTCOMBATDIRSSACT) 

FKP15  ( INTCOMBATSYSTESFAC ) 

FRQ3A  ( NAVELEXSY  SENGCEN ) 

FKQ3B  (NAVELEXSYSENGACTDET) 

FKR3C  (  N  AV  AIRTEST  CEN  ) 

FKR4A  (PACMISTESTCEN) 

FKR5  (NAVAVIONICCEN) 

FS1  (COMNAVINTCOM) 

FT1  (CNET) 

FT73  (NAVPGSCHOL)  (Computer  Science,  Engineering,  and  Library  Depts 

only) 

26F  (OPTEVFOR) 

V12  (Development  and  Education  Command,  Marine  Corps;  MCTSSA) 

ASN(MRA&L  and  RE&S)  (2  copies  each) 

NAVMAT  SP  List  2 

Defense  Systems  Management  College  (Technical  Management  Division) 


Copy  to: 

CNO  (OP-942E3,  -982F3) 

DASN(C^I)  (Special  Assistant  for  Computer  Programs) 


TADSTAND  D 


“RESERVE  CAPACITY  REQUIREMENTS  FOR 
TACTICAL  DIGITAL  SYSTEMS" 

ABSTRACT 


•  Establishes  reserve  capacity  requirements  for  embedded  computers. 

•  Defines  reserve  requirements  for  the  following: 

•  Main  memory 

•  Secondary  storage 

•  Throughput 

•  Number  of  Input/Output  Channels 

•  Input/Output  Channels  throughput. 


DEPARTMENT  OF  THE  NAVY 
HEADQUARTERS  NAVAL  MATERIAL  COMMAND 
WASHINGTON.  D.C.  20360 


IN  REPLY  REFER  TO 


08Y/RJH 

T-9 

Ser  239 
2  July  1980 


TACTICAL  DIGITAL  STANDARD  (TAD STAND)  D 

From:  Chief  of  Naval  Material 

Subj:  Reserve  Capacity  Requirements  for  Tactical  Digital  Systems 

Ref:  (a)  NAVMATINST  5430.60  of  10  July  1978;  Headquarters  Naval  Material 

Command  Organization  Manual 

(b)  CNM  ltr  09Y/CFH  Ser  134  of  9  May  1972;  Standard  Reserve  Capacitiy 
Requirements  for  Digital  Combat  System  Processors  (TADSTAND  5) 

(c)  CNM  ltr  08Y/DCR  Ser  230  of  2  July  1980;  Standard  Definitions  for 
Tactical  Embedded  Computer  Resources  (TADSTAND  A) 

(d)  DoD  Instruction  5000.2  of  19  March  1980;  Major  System  Acquisition 
Procedures 

(e)  DoD  Directive  5000.29  of  26  April  1976;  Management  of  Computer 
Resources  in  Major  Defense  Systems 

(f)  SECNAVINST  5200.32  of  11  June  1979;  Management  of  Embedded 
Computer  Resources  in  Department  of  Navy  Systems 

1.  Purpose.  In  accordance  vith  reference  (a),  this  TADSTAND  is  promulgated 

to  establish  reserve  capacity  requirements  for  embedded  computers  (ECs)  in 

Tactical  Digital  Systems  undeT  the  cognizance  of  the  Naval  liaterial  Command. 

This  TADSTAND  supersedes  reference  (b). 

2.  Cancellation.  Effective  this  date,  reference  (b)  is  cancelled. 

3.  Definitions.  The  following  terms  are  defined  in  reference  (c): 

a.  Embedded  Computer  (EC) 

b.  Main  Memory 

c.  Secondary  Storage 

d.  Tactical  Digital  Systems 


4.  Applicability. 


a.  This  TADSTAND  applies  to  all  tactical  digital  systems  under  the 
cognizance  of  the  Naval  Material  Connand.  This  TADSTAND  also  applies  to 
development  programs  under  the  cognizance  the  Naval  Material  Command  that  are 
ultimately  intended  to  be  employed  as  tactical  digital  systems  or  as 
components  thereof.  Except  as  noted  in  paragraph  4.b  below,  this  encompasses 
all  phases  of  the  life  cycle  of  tactical  digital  systems  including  design, 
development,  production,  installation,  major  upgrade,  and  operational  support 
throughout  the  service  life  of  the  system. 
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b.  In  the  specific  case  of  major  system  acquisitions  that  are  based  on 
reference  (d),  the  provisions  of  this  TADSTAND  need  not  be  applied  prior  to 
the  Demonstration  and  Validation  phase.  In  these  instances,  acquisition 
managers  must  ensure  that  contractors  are  aware  that  the  provisions  of  this 
TADSTAND  will  be  applied  to  all  phases  of  the  acquisition  commencing  with  the 
Demonstration  and  Validation  phase. 

c.  The  provisions  of  this  .TADSTAND  are  not  to  be  applied  retroactively. 
All  existing  systems  must  have  been  in  compliance  with  reference  (b). 
Otherwise,  a  waiver  request  must  be  submitted  within  90  days  from  the 
effective  date  of  this  TADSTAND.  For  those  instances  in  which  systems  were  in 
compliance  with  reference  (b)  but  are  not  in  compliance  with  this  TADSTAND, 
the  provisions  of  this  TADSTAND  need  not  be  applied  until  the  system  is 
modified,  as  provided  in  paragraph  6. a  below. 

5 .  Background. 

a.  Reference  (e),  as  implemented  by  reference  (f),  establishes  DoD 
policy  for  the  management  and  control  of  computer  resources  during  the 
development,  acquisition,  deployment,  and  support  of  major  Defense  systems. 
These  policies  are  applicable  to  all  Defense  systems  except  general  purpose, 
commercially-available  ADP  systems  that  are  subject  to  other  regulations. 

b.  EC s  have  been  employed  successfully  in  a  wide  range  of  tactical 
digital  systems  for  surface  ships,  submarines,  and  aircraft.  Applications 
using  ECs  include  missile,  gun,  and  underwater  fire  control;  signal 
processing;  navigation;  and  command,  control,  and  communications. 

c.  Failure  to  specify  and/or  maintain  adequate  reserve  capacities  in 
memory,  throughput,  and  input/output  of  ECs  during  development  and  initial 
acquisition  has  all  too  frequently  resulted  in  delivery  of  systems  to  the 
fleet  that  have  no  reserve  capacity  for  change,  update,  and  growth.  Costly 
reprograming  or  the  introduction  of  additional  embedded  computers  are  then 
the  only  solutions  that  will  satisfy  new  system  requirements. 

d.  Reference  (b)  was  developed  in  1972  to  deal  with  the  multitude  of 
problems  that  resulted  from  the  historical  lack  of  reserve  capacity  in  the 
development  of  tactical  digital  systems. 

6.  Policy. 

a.  Reserve  capacity  requirements  shall  be  applied  to  the  first 
production  delivery  to  the  fleet  of  a  new  system  or  a  modified  system  that 
incorporates  new  ECs  or  hardware  modifications  to  ECs  already  in  the  system. 

b.  These  reserve  capacity  requirements  shall  also  apply  to  a  system  when 
installed  on  a  new  platform  if  any  modifications,  hardware  or  software,  are 
required  for  such  an  installation. 
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c.  If  the  system  has  multiple  configurations,  the  reserve  capacity 
requirements  shall  apply  to  all  configurations  individually. 

d.  Capacities  reserved  for  future  growth,  when  the  growth  requirements 
are  known  prior  to  acquisition  commitment  to  the  configuration  of  a  new  or 
modified  system,  shall  not  be  included  in  the  reserve  required  by  this 

TAD STAND.  Reserve  capacity  requirements  specified  by  this  TAD STAND  are  for 
future  growth  requirements  that  are  not  known  at  the  time  of  acquisition 
commitment  and  first  production  delivery. 

7.  Reserve  Capacity  Requirements,  Effective  this  date,  project  and 
acquisition  managers,  and  other  development  and  support  activities,  shall 
comply  with  the  reserve  capacity  requirements  identified  below. 

a.  Main  Memory.  Main  memory  shall  have  a  20Z  reserve  capacity,  as  a 
minimum.  The  reserve  capacity  shall  be  measured  at  peak  main  memory  loading 
of  the  EC  during  its  operational  missions.  Peak  main  memory  loading  shall 
include  all  programs  and  data  required  for  successful  operational  mission 
execution.  The  reserve  capacity  need  not  be  physically  installed  in  the  EC, 
but  no  cabinet,  chassis,  or  backplane  modifications  shall  be  required  for  its 
installation,  except  in  the  case  of  the  AN/UYK-7  as  follows:  reserve  capacity 
may  include  conversion  of  AN/UYK-7  single  density  magnetic  core  memory  to 
AN/UYK-7  double  density  mated  film  memory  even  though  this  conversion  requires 
backplane  modifications. 

b.  Secondary  Storage.  Secondary  storage  shall  have  a  20Z  reserve 
capacity,  as  a  minimum.  The  reserve  capacity  shall  be  measured  at  peak 
secondary  storage  loading  of  the  EC,  with  all  secondary  storage  information 
included,  during  its  operational  missions.  When  secondary  storage  consists  of 
multiple  units  and/or  types  of  units,  the  reserve  capacity  shall  apply  to  the 
stas  total  of  all  secondary  storage  reserve  capacity.  The  reserve  capacity 
need  not  be  physically  installed,  but  no  cabinet,  chassis,  or  backplane 
modifications  shall  be  required  for  its  installation. 

c.  Throughput.  Central  processor  throughput  shall  have  a  20Z  reserve 
capacity,  as  a  minimum.  The  reserve  capacity  shall  be  expressed  as  a 
percentage  of  available  capacity  at  full  operational  loading  over  a  specific 
period  of  time,  as  determined  by  operational  mission  characteristics.  In  the 
case  of  cyclic  applications,  such  as  some  signal  processing  applications,  this 
period  would  be  the  time  between  availability  of  successive  input  data  buffers. 

d.  Number  of  Input/Output  Channels.  The  number  of  reserve  input/output 
channels  shall  be  18.75Z  (3/16)  of  those  available,  as  a  minimum.  The  reserve 
channels  need  not  be  physically  installed  in  the  EC,  but  no  cabinet,  chassis, 
or  backplane  ircdificatiooa  shall  be  required  for  their  installation. 

e.  Input/Output  Channel  Throughput.  Input/output  channels  shall  each 
have  a  20Z  reserve  capacity  in  throughput,  as  a  minimum.  The  reserve  capacity 
shall  be  expressed  as  in  paragraph  7.c  above. 
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8.  Deviations. 

a.  It  is  recognized  that,  in  some  cases,  strict  adherence  to  this 
TADSTAND  could  be  technically  infeasible,  economically  prohibitive,  or 
operationally  impracticable.  When  a  deviation  is  considered  to  be  in  the  best 
interests  of  the  Navy,  a  TADSTAND  waiver  may  be  granted  by  the  Chief  of  Naval 
Material  (CNM). 

b.  Waiver  requests  shall  be  submitted  to  CNM  (Attn:  MAT  08Y)  via  PMS-408 
or  PMA-533,  as  appropriate.  Each  request  will  be  considered  on  a  case-by-case 
basis.  In  order  to  preclude  implied  waivers,  a  waiver  is  required  for  each 
specific  element  of  a  developing  system  or  subsystem  for  which  a  deviation  is 
deemed  necessary.  To  minimize  the  fiscal  or  schedule  impact  of  this  TADSTAND 
on  projects,  cognizant  agencies  are  enjoined  to  conduct  liaison  with  the  Chief 
of  Naval  Material  (MAT  08Y)  prior  to  commitment  to  a  specific  course  of  action 
that  could  potentially  result  in  a  request  for  a  TADSTAND  waiver. 

c.  A  waiver  request  shall  include  the  following  information: 

(1)  Name,  function(s),  and  operating  description  of  system  for 
which  waiver  is  requested. 

(2)  Platform(s)  on  which  system  is  to  be  installed. 

(3)  All  embedded  computer  resources  (computers,  peripherals, 
displays,  I/O  interfaces,  etc.)  and  functions  of  each  as  well  as  system  block 
diagram(s)  depicting  the  interconnection  of  these  resources. 

(4)  Storage  and  I/O  requirements  and  throughput  parameters. 

(5)  Software  constraints  (e.g. ,  timing  and  space). 

(6)  Environmental  requirements  and/or  constraints  on  the  embedded 
computer  resources. 

(7)  Estimated  or  known  reduction  of  the  reserve  capacity 
requirements. 

(8)  Cause  of  reduction  from  the  reserve  capacity  requirements. 

(9)  Impact  in  terms  of  system  performance,  cost,  and  schedule  if 
waiver  from  requirements  is  not  approved. 

(10)  Known  or  anticipated  requirements  for  usage  of  memory, 
throughput,  and  input/output  for  future  upgrades. 
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9.  Inquiries.  Inquiries  concerning  the  application  or  intrepretation  of  this 
and  other  TADSTANDs  should  be  addressed  to: 


Chief  of  Naval  Material  (Attn:  MAT  08Y) 
Navy  Department 
Washington,  D.  C.  20360 
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Distribution: 

SNDL  A3  (CNO)  (OP  112,  22,  211,  224,  35,  351,  04,  55,  551,  94,  940,  941, 
942,  944,  95,  98,  982,  983,  only) 

A2A  (CNR)  (Codes  240  and  437  only) 

A6  (Headquarters,  U.S.  Marine  Corps)  (Codes  LMC-3  and  CCA4  only) 

C4K  (CNM  PMs) 

E3A  (Lab  ONR)  (NRL  only)  (3  copies) 

FE1  (COMNAVSECGRD ) 
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FKPlG  (NAVSHIPWPNSYSENGSTA) 

FKP14  (FLTCOMBATDIRSSACT) 
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FKQ3A  ( NAVELEXSY SENGCEN ) 
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FT1  (CNET) 
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only) 
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TADSTAND  E 


TO  BE  RELEASED.  ONCE  RELEASED,  WILL  SUPERCEDE 
TADSTANDS  2.  3  AND  9. 


ABSTRACT 


•  Will  require  software  documentation  development,  and  testing  in  accordance  with  MIL 
STD- 1679. 


DEPARTMENT  OF  THE  NAVY 
-  E  ADQU  ART  ;  RS  NAVAl.  MA'  =  =>.Au  COMMAND 

a  ashington  DC  2036C  , 

TADSTAND  E 
MAT  08 Y 

2  3  .'"ay  198  2 


TACTICAL  DIGITAL  STANDARD  E 
From:  Chief  of  Naval  Material 

Subj:  Software  Development,  Documentation,  and  Test-ng  Policy  for  Navy 

Mission  Critical  Systems 

Ref:  (a)  NAVMATINST  5430. 60A  of  9  November  1981;  Headquarters  Naval 

Material  Conmand  Organization  Manual 

(b)  CNM  ltr  09Y:JDC  Ser  299  of  1  November  1974;  Standard  Specification 
for  Tactical  Digital  Computer  Program  Documentation  (TADSTAND  2 
(Revision  1)) 

(c)  CNM  ltr  09Y:JDC  Ser  304  of  5  November  1974;  Standard  Requirements 
for  Inter -Digital  Processor  Interface  Documentation  (TADSTAND  3 
(Revision  1)) 

(d)  CNM  ltr  09Y/WAP  Ser  260  of  18  August  1978;  Software  Quality 
Testing  Criteria  Standard  for  Tactical  Digital  Systems  (TADSTAND  9) 

(e)  CNM  ltr  08Y/DCR  Ser  230  of  2  July  1980;  Standard  Definitions  for 
Embedded  Computer  Resources  in  Tactical  Digital  Systems 
(TADSTAND  A) 

(f)  CNM  ltr  Ser  00/0991  of  3  November  1981:  Standard  Navy  Tactical 
Embedded  Computer  Resources  (TECR);  use  of  in  all  phases  of  system 
developments 

(g)  NAVMATINST  5200. 27A  of  18  April  1973;  Transfer  of  Navy  Tactical 
Digital  System  Software  Responsibility;  procedures  for 

(h)  NAVMATINST  4130. 2A  of  19  July  1976;  Configuration  Management  of 
Computer  Software 

(i)  SECNAVINST  3560.1  of  8  August  1974;  Tactical  Digital  Systems 
Documentation  Standards 

(j)  MIL-STD-1679  (NAVY);  Weapon  System  Software  Development 

1.  Purpose.  In  accordance  with  reference  (a),  this  TADSTAND  promulgates 
standardization  policy  for  the  development,  documentation,  and  testing  of 
software  used  in  the  development,  acquisition,  deployment,  and  support  of  Navy 
mission  critical  systems.  This  TADSTAND  supersedes  TADSTANDs  2,  3,  and  9 
(references  (b),  (c),  and  (d)),  which  covered  specifications  for  tactical 
digital  computer  program  documentation,  requirements  for  inter-digital 
processor  interface  documentation,  and  software  quality  testing  criteria, 
respectively. 

2.  Cancell  at ion.  Effective  this  date,  TADSTANDs  2,  3,  and  9  are  cancelled. 
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3.  Definitions 


a.  Mission  Critical  Systems  are  those  systems  which  are  required  for  the 
conduct  of  the  military  mission  of  the  Department  of  Defense.  This  definition 
includes  systems  related  to: 

(1)  Intelligence  activities. 

(2)  Cryptology  activities  related  to  National  security. 

(3)  Command  and  control  of  military  forces. 

(4)  A  weapon  or  weapon  system. 

(5)  The  direct  fulfillment  of  military  or  intelligence  missions,  but 
not  routine  administrative  or  business  applications. 

This  definition  also  includes  tactical  digital  systems,  as  defined  in 
TADSTAND  A,  reference  (e),  as  well  as  those  “ADPE"  or  "ADP"  systems  required 
for  the  direct  support  of  mission  critical  systems. 

b.  Mission  Critical  Computer  Resources  (MCCR)  are  those  computer 
resources  required  for  the  conduct  of  the  military  mission  of  the  Department 
of  Defense.  This  definition  includes  embedded  computer  resources,  as  defined 
in  TADSTAND  A,  used  in  mission  critical  systems,  as  well  as  those  "ADPE"  or 
"ADP"  resources  required  for  the  direct  support  of  mission  critical  systems. 

c.  Tailoring  is  the  process  by  which  individual  requirements  (sections, 
paragraphs,  or  sentences)  of  a  specification,  standard,  or  data  requirement 
are  evaluated  to  determine  the  extent  to  which  they  are  most  suitable  for  a 
specific  system,  and  the  modification  or  deletion  of  some  requirements  to 
ensure  that  each  achieves  an  optimal  balance  between  operational  needs  and 
cost. 

d.  The  following  terms  are  defined  in  TADSTAND  A: 

(1)  Embedded  Computer  (EC) 

(2)  Embedded  Computer  Resources  (ECR) 

(3)  Major  Upgrade 

(4)  Software  (application  and  support) 

(5)  Standard 

(6)  Tactical  Digital  System 
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4.  App 1 i cabi 1 ity 

a.  This  TADSTAND  applies  to  all  mission  critical  systems  under  the 
cognizance  of  the  Chief  of  Naval  Material  (CHNAVMAT)  that  use  embedded 
computer  resources.  This  TADSTAND  also  applies  to  mission  critical 
development  programs  under  the  cognizance  of  CHNAVMAT  that  are  ultimately 
intended  to  be  employed  as  mission  critical  systems  or  as  components  thereof. 

b.  In  accordance  with  reference  (f),  this  TADSTAND  applies  to  all  phases 
of  system  acquisition  (i.e.,  initial  concept  formulation  and  requirements 
definition,  design,  development,  installation,  production,  and  post  deployment 
support  throughout  the  service  life  of  the  system),  regardless  of  funding  or 
acquisition  category. 

c.  The  provisions  of  this  TADSTAND  are  not  to  be  applied  retroactively  to 
systems  for  which  computer  software  development,  documentation,  or  testing 
commitments  have  already  been  made.  However,  commitments  made  prior  to  the 
effective  date  of  this  TADSTAND  must  have  been  in  compliance  with  the 
superseded  TADSTANDs  (see  paragraph  1  above).  Compliance  includes  conformance 
to  previously  designated  standards  or  a  CHNAVMAT  approved  waiver.  Otherwise, 
a  waiver  request  must  be  submitted  within  60  days  of  the  effective  date  of 
this  TADSTAND. 

5.  Background 


a.  There  is  a  growing  concern  over  the  high  cost  of  software  development 
and  life  cycle  support  within  the  Department  of  Defense.  The  reliability  and 
supportabil ity  of  many  of  these  systems  are  also  matters  of  concern.  Part  of 
the  problem  has  been  the  difficulty  in  establishing  meaningful  system 
operational  and  performance  requirements  for  software,  supported  by  objective 
test  criteria  for  determining  the  correctness  of  the  software.  Also  lacking 
are  adequate  management  controls  which  govern  the  software  development, 
acquisition,  and  life  cycle  support  process.  Program  and  acquisition  managers 
must  have  clear  and  detailed  guidance  in  order  to  specify  uniform  computer 
software  development,  documentation,  and  life  cycle  support  requirements  in 
system  specifications  and  statement  of  work  documents.  Initial  steps  in 
correcting  the  problem  areas  were  taken  by  CHNAVMAT  in  the  issuance  of 
TADSTANDs  2,  3,  and  9,  and  NAVMAT  Instructions  5200. 27A  and  4130. 2A, 
references  (g)  and  (h). 

b.  TADSTANDs  2  and  3  invoked  SECNAVINST  3560.1,  reference  (i),  as  the 
required  standard  for  documenting  both  tactical  digital  computer  programs  and 
inter-digital  processor  interfaces  within  a  computer  program. 

SECNAVINST  3560.1  has  not  been  uniformly  implemented,  however,  because  of  a 
lack  of  direction  on  specific  Data  Item  Descriptions  (DIDs)  for  tactical 
digital  software  documentation.  As  a  result,  there  has  been  a  proliferation 
of  Unique  Data  Item  Descriptions  (UDIDs). 
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c.  TADSTAND  9  invoked  standard  software  quality  testing  criteria  for 
tactical  digital  systems.  TADSTAND  9  was  primarily  concerned  with  the  final 
software  testing  to  be  conducted  on  a  program  prior  to  acceptance  of  tne 
program  by  the  Navy,  rather  than  the  full  range  of  requirements  covering  the 
complete  software  development  orocess.  TADSTAND  9,  therefore,  applied  more  to 
Navy  software  acquisition  managers  than  to  software  contractors. 

d.  NAVMATINST  5200. 27A  promulgated  policies  and  procedures  for 
transitioning  software  from  the  development  phase  of  the  life  cycle  to  the 
support  phase.  NAVMATINST  4130. 2A  delineated  the  responsibilities  of  Navy 
Systems  Commanders  and  Program  Managers  regarding  configuration  management  of 
software  and  related  documentation. 

e.  Subsequent  to  issuance  of  TADSTANDS  2,  3,  and  9,  CHNAVMAT  developed 
the  reference  (j)  military  standard  M IL - STD- 1679  (Navy),  Weapon  System 
Software  Development,  which  complements  these  three  TADSTANDs  and  is 
duplicative  of  them  in  some  areas.  M IL - STD- 1679  establishes  minimum  uniform 
requirements  covering  the  complete  development  process  of  weapon  system 
software,  including  program  test,  quality  assurance,  and  program  acceptance 
criteria.  The  DIDs  listed  in  MIL -ST D- 1679  are  specifically  designed  to 
control  the  software  development  process  and  obtain  the  documentation  that  is 
required  for  effective  configuration  management  and  post  deployment  support  of 
mission  critical  system  software.  Additionally,  M IL -STD- 1679  can  be  invoked 
by  reference  in  Navy  software  development  contracts,  tasking  agreements,  ana 
specifications. 

6.  Policy.  For  applicable  mission  critical  systems: 

a.  All  software  shall  be  developed,  documented,  tested,  and  supported  in 
accordance  with  the  provisions  of  MIl-STD-1679  (Navy),  Weapon  System  Software 
Development. 

b.  MIL-STD-1679  and  its  companion  DIDs  shall  be  invoked  in  all  new 
contracts,  tasks,  agreements,  etc.,  for  the  development,  documentation,  or 
testing  of  all  software.  MIL-STD-1679  shall  also  be  invoked  in  new  contracts, 
tasks,  agreements,  etc.,  for  modification  or  revision  to  existing  software. 

c.  The  invoking  of  MIL-STD-1679  on  any  organization  under  contract  or 
tasking  arrangement  to  perform  any  part  of  the  software  development  effort 
shall  not  relieve  the  Navy  development  activity  or  acquisition  manager  (e.g., 
Procuring  Agent/Agency,  Program  Manager)  from  further  responsibi 1 ity  regarding 
the  requirements  of  this  TADSTAND.  Ultimate  responsibi 1 i ty  for  ensuring  that 
the  principles  and  requirements  of  MIL-STD-1679  are  adhered  to  rests  with  the 
Navy  development  activity  or  acquisition  manager. 
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d.  The  software  quality  testing  criteria  delineated  in  M I L -  STD- 1679  , 
paragraph  5.10  (Program  Acceptance),  shall  be  satisfied  prior  to  initial 
operational  use  or  fleet  introduction  of  the  system  and  for  all  subsequent 
major  upgrades,  including  site  dependent  configuration  variations  within  a 
major  upgrade,  throughout  the  life  cycle  of  the  system. 

e.  MIL-STD-1679 ,  except  for  Section  6  (Miscellaneous),  constitutes  the 
minimum  requirements  for  all  software  development.  Therefore,  with  the 
exception  of  Section  6,  tailoring  of  MIL-STD-1679  is  not  allowed.  Specific 
guidelines  for  tailoring  Section  6  are  covered  in  paragraph  6.f  below. 

f.  Except  as  specified  below,  the  DIDs  listed  in  MIL-STD-1679,  Section  6, 
constitutes  the  minimum  set  of  required  software  documentation.  This  minimum 
set  is  required  for  the  majority  of  applicable  Navy  systems  and  subsystems, 
characterized  by  such  systems  as  NTDS,  AEGIS,  TRIDENT  CCS,  AN/SLQ-32,  etc.  In 
some  instances,  however,  depending  primarily  on  system  size  and/or  complexity, 
it  may  not  always  be  appropriate  to  develop  the  complete  minimum_set  of 
software  documentation.  In  these  instances,  limited  tailoring  of 
MIL-STD-1679,  Section  6,  and  the  individual  DIDs,  is  allowed  as  follows; 
however,  in  no  case  will  such  tailoring  result  in  the  development  of  a  new 
DID,  i .e. ,  a  UDID. 

(1)  The  Interface  Design  Specification  is  not  required  when  there  is 
no  interface  with  other  systems  or  subsystems. 

(2)  The  Program  Design  Specification  may  be  tailored  such  that  the 
unique  elements  of  the  Program  Design  Specification  and  the  Program 
Description  Document  are  contained  in  the  Program  Design  Specification,  and 
the  Program  Description  Document  is  then  not  required. 

(3)  The  Computer  Program  Test  Plan  may  be  tailored  such  that  the 
unique  elements  of  the  Computer  Program  Test  Plan,  the  Computer  Program  Test 
Specification,  and  the  Computer  Program  Test  Procedures  are  contained  in  the 
Computer  Program  Test  Plan,  and  the  Computer  Program  Test  Specification  and 
Computer  Program  Test  Procedures  are  then  not  required. 

(4J  The  System  Operator's  Manual  may  be  tailored  such  that  the  unique 
elements  of  the  System  Operator's  Manual  and  the  Operator's  Manual  are 
contained  in  the  Systems  Operator's  Manual,  and  the  Operator's  Manual  is  then 
not  required. 

(5)  In  NAVAIR  systems  for  which  Naval  Aviation  Training  and  Operating 
Procedures  Standardization  (NATOPS)  documentation  is  provided,  the  Systems 
Operator's  Manual  and  the  Operator's  Manual  are  not  required. 
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g.  The  minimum  required  documentation  set  specified  in  MIL -STD- 1679  may 
be  expanded  to  meet  specific  project  requirements;  however,  all  documents 
developed  in  addition  to  those  described  in  MIL -STD-1679  shall  be  in 
accordance  with  SECNAVINST  3560.1. 

h.  Transfer  of  software  responsibil ity  from  a  development  activity  to  a 
support  activity  will  be  accomplished  in  accordance  with  the  provisions  of 
NAVMATINST  5200. 27A. 

i.  Configuration  management  of  software  and  related  documentation  will  be 
in  accordance  with  the  provisions  of  NAVMATINST  4130. 2A. 

7.  Waivers. 

a.  It  is  recognized  that,  in  some  cases,  strict  adherence  to  this 
TADSTAND  could  be  impracticable  or  economically  prohibitive.  When  an 
exception  to  this  standard  is  considered  to  be  in  the  best  interests  of  the 
Navy,  a  TADSTAND  E  waiver  may  be  granted  by  CHNAVMAT.  However,  proceeding 
with  a  software  development  in  violation  of  this  TADSTAND  without  first 
obtaining  a  waiver  from  CHNAVMAT  may  result  in  unforeseen  schedule  and/or 
financial  impact  on  the  project  due  to  possible  waiver  disapproval.  To  avoid 
the  adverse  impact  which  may  result  in  such  cases,  cognizant  agencies  are 
encouraged  to  conduct  liaison  with  CHNAVMAT  (MAT  08Y)  prior  to  commitment  to  a 
specific  course  of  action  that  could  potentially  result  in  a  request  for  a 
TADSTAND  E  waiver. 

b.  TADSTAND  E  waiver  requests  shall  be  submitted  to  the  Chief  of  Naval 
Material.  Each  approved  waiver  will  be  effective  only  until  the  next  major 
upgrade  of  the  system  concerned.  When  a  major  upgrade  is  planned,  a  new 
waiver,  if  warranted,  must  be  approved  by  CHNAVMAT.  Each  request  will  be 
considered  on  a  case-by-case  basis.  In  order  to  preclude  implied  waivers,  a 
waiver  is  required  for  each  specific  element  of  an  applicable  system  or 
subsystem  for  which  an  exception  is  deemed  necessary. 

c.  A  TADSTAND  E  waiver  request  shall  include  the  following  information: 

(1)  Point(s)  of  contact  for  technical  and  management  information, 
including  name(s),  phone  number (s),  and  location(s). 

(2)  Name,  function(s),  and  operating  description  of  the  system  for 
which  the  waiver  is  requested. 

(3)  Platform(s)  on  which  system  is  to  be  installed. 

(4)  All  mission  critical  computer  resources  and  functions  of  each  as 
well  as  system  block  diagram(s)  depicting  the  interconnection  of  these 
resources. 


290 


Subj:  Software  Development,  Documentation,  and  Testing  Policy  f  c' 
Mission  Critical  Systems 

(5)  Approved  software  development  schedules,  together  with  v 
milestones. 

(6)  Estimated  size  (number  of  computer  words)  of  program(s)  to  : 
developed. 

(7)  Reasons  (e.g.,  cost,  performance,  schedule)  for  requesting  t 
waiver,  including  supporting  rationale.  Cost  figures,  if  used,  must  ref 
the  total  system  life  cycle,  as  opposed  to  development  cost  only. 

(8)  Proposed  alternative(s),  if  applicable,  together  with  suppor 
rati onal e. 

8.  Inquiries.  Inquiries  concerning  the  application  or  interpretation  c 
and  other  TADSTANDs  should  be  addressed  to: 

Chief  of  Naval  Material  (Attn:  MAT  08V) 

Navy  Department 
Washington,  D.  C.  20360 

Phone:  Autovon  222-3966;  Commercial  (202)  692-3966 


/ 
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"WEAPON  SYSTEM  SOFTWARE  DEVELOPMENT" 


ABSTRACT 


•  Contains  the  requirements  for  the  design  and  development  of  weapon  system  software. 

•  Establishes  uniform  requirements  for  the  development  of  weapon  system  software. 

•  "Strict  adherence  will  ensure  that  the  weapon  system  software  so  developed  possesses 
the  highest  degree  of  reliability  and  maintainability  feasible." 
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DEPARTMENT  OF  DEFENSE 
Washington,  DC  20360 


Weapon  System  Software  Development 
MU- STD- 16  79  (Navy) 


1.  This  Military  Standard  Is  approved  for  use  by  the  Department  of  the  Navy  and  is 
available  for  use  by  all  Departments  and  Agencies  of  the  Department  of  Defense. 

2.  Beneficial  comments  (reconaendations ,  additions,  deletions)  and  any  pertinent  data 
which  may  be  of  use  in  improving  this  document  should  be  addressed  to: 

Chief  of  Naval  Material 
ATTN :  NAVMAT  09Y 
Washington,  DC  20360 


by  using  the  self-addressed  Standardization  Document  Improvement  proposal  (DD  Form 
1426)  appearing  at  the  end  of  this  document  or  by  letter. 
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FOREWORD 

1.  This  standard  contains  requirements  for  the  design  and  development  of  weapon  system 
software  which  are  applicable  in  government  contracts.  A  standard  specifically  addressing 
weapon  system  software  is  necessary  because  of  factors  concerning  this  software  which  are 
not  common  to  general  software,  or  which  carry  a  significantly  different  degree  of  empha¬ 
sis.  Major  factors  are: 

a.  Criticality  of  performance.  The  combat  capability  of  weapon  systems  and  the  com¬ 
bat  survivability  of  combatant  units  of  the  operating  forces  depend,  in  part, 
upon  the  effective  operation  of  the  weapon  system  software.  Therefore,  extra¬ 
ordinary  efforts  are  justified  in  the  development  phase  to  ensure  maximum  re¬ 
liability  and  maintainability.  Special  emphasis  snail  be  placed  on  the  accu¬ 
racy  and  effective  operation  of  the  software. 

b.  Changing  operational  requirement.  Weapon  system  software  implements  weapon  system 
operations  and  doctrine  in  areas  susceptible  to  many  changes  of  performance  re¬ 
quirements.  These  changes  often  Impact  the  software  and  need  expeditious  imple¬ 
mentation.  This  demands  that  weapon  system  software  be  designed  to  facilitate 
efficient  change,  sometimes  at  the  expense  of  technical  design  efficiency.  Con¬ 
tinuation  of  an  efficient  change  capability  over  the  operational  life  of  the  weap¬ 
on  system  also  requires  detailed  documentation  describing  the  software.  Pro¬ 
posed  changes  and  their  total  impact  must  be  easily  discernible  and  capable  of 
being  implemented  by  personnel  not  associated  with  the  original  development  ef¬ 
fort  . 

c.  Life-cycle  cost.  Development  and  implementation  of  changes  to  weapon  system 
software  over  the  operational  life  of  the  weapon  system  are  costly.  The  design 
of  the  software  during  development  must  be  strongly  influenced  by  factors  which 
will  reduce  life-cycle  cost.  Among  these  are  various  standardization  require¬ 
ments,  such  as  those  imposed  upon  program  design,  languages,  and  Intersystem 
and  Intrasystem  interfaces.  An  additional  benefit  of  these  standardization  re¬ 
quirements  is  to  ensure  chat  changes  developed  and  implemented  in  one  system 
will  have  applicability  in  other  systems. 

2.  Data  Item  Descriptions  (DlDs)  applicable  to  this  standard  are  listed  in  Section  6. 
These  are  essentially  the  same  as  previously  used  descriptions  of  data  customarily  re¬ 
quired  in  connection  with  weapon  system  software  development.  The  majority  have  been  ex¬ 
tracted  from  official  military  documentation  standards.  Others  have  been  developed 
through  the  experience  gained  by  military  and  commercial  software  developing  activities. 
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1 .  SCOPE 


1.1  Purpose.  This  standard  astabllshss  uniform  raqulramanta  for  the  development  of 
weapon  system  software  within  the  Department  of  Defense.  Strict  adherence  to  the  pro¬ 
visions  of  this  standard  will  ensure  that  the  weapon  system  software  so  developed  pos¬ 
sesses  the  highest  degree  of  rellsblllty  and  maintainability  feasible. 

1.2  Application.  When  Invoked  In  a  specification  or  statement  of  work,  these  require¬ 
ments  shall  apply  to  the  weapon  system  software  (Including  firmware)  which  Is  developed 
either  alone  or  as  a  portion  of  a  weapon  system  or  subsystem  development.  The  contractor 
Is  responsible  for  Invoking  all  the  applicable  requirements  of  this  Military  Standard  on 
any  and  all  subcontractors  he  may  employ. 
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2.  REFERENCE  DOCUMENTS 


2.1  Issues  of  documents.  The  following  docimients  of  the  lisue  in  effect  on  the  date  of 
Invitation  for  bids  or  request  for  proposal  fora  a  part  of  this  standard  to  the  extent 
specified  herein. 

a.  D0D-STD-480A;  Configuration  Control  -  Engineering  Changes,  Deviations  and 
Waivers. 

b.  MIL- STD-481;  Configuration  Control  -  Engineering  Changes,  Deviations  and  Waivers 
(Short  Fora). 

c.  Headquarters  Naval  Material  Coanand;  "Tactical  Data  Systeas  Glossary", 

(Defense  Documentation  Center  Accession  Number  AD-A056868.) 

d.  ANSI  3.12  -  1970;  Vocabulary  for  Information  Processing. 

e.  NAVSO  ADP  Glossary  (NAVSO  P-3097). 

(Copies  of  specifications,  standards,  drawings  and  publications  required  by  contractors 
in  connection  with  specific  procurement  functions  should  be  obtained  froa  the  procuring 
agency  or  as  directed  by  the  contracting  officer.) 


2 • 2  Ocher  publications.  None . 
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3.  DEFINITIONS 


3.1  Weapon  syatem.  Any  system  or  subsystem  contributing  to  the  combat  capability  of 
the  operating  forces  -  land,  air,  sea  and  undersea  sensor  systems,  command  and  control 
systems,  intelligence  systems,  consnunications  systems,  ship  and  aircraft  control  systems, 
navigation  systems  and  certain  associated  ground  based  systems  are  included.  Systems  or 
subsystems  serving  both  the  individual  unit  and  those  supporting  a  tactical  commander 
fall  within  the  definition.  Logistic  support  systems  and  ADP  systems  devoted  to  manage¬ 
ment  functions  are  excluded  only  if  their  operations  do  not  impact  weapon  systems.  When 
used  in  the  phrase  "weapon  system  software"  (as  in  this  standard),  a  digital  weapon 
system  is  implied. 

3.2  Weapon  system  software.  The  totality  of  software  (programs,  firmware  and  data 
bases)  associated  with  a  weapon  system.  Weapon  system  software  Includes  that  software 
which  is  in  the  weapon  system,  in  the  test  and  maintenance  equipment  for  the  weapon  system, 
in  the  trainer  equipment  for  the  weapon  system  and  Includes  the  support  software  used  to 
develop,  test  and  support  the  weapon  system  software.  This  definition  of  weapon  system 
software  is  Independent  of  the  type  of  physical  storage  media  in  which  the  software  re¬ 
sides.  Within  the  context  of  this  Military  Standard,  weapon  syatem  software  is  equiva¬ 
lent  to  and  synonymous  with  the  software  portion  of  "Embedded  Computer  Resources". 

Also,  within  the  context  of  this  standard,  the  terms  "program",  "computer  program"  and 
"digital  processor  program"  are  considered  to  be  synonymous  and  are  used  interchangeably 
as  is  grammatically  appropriate  with  no  distinction  intended.  These  terms  (program,  etc.) 
are  equivalent  to  weapon  system  software  or  one  independent  part  of  the  software  of  a 
weapon  system,  depending  upon  the  complexity  of  any  particular  weapon  system.  Within 
this  standard,  unless  specifically  stated  otherwise,  software  is  equivalent  to  weapon 
system  software.  The  term  "digital  processor"  implies  a  digital  computer,  whether 
micro,  mini,  or  full  size. 

Weapon  system  software  is  categorized  as  follows. 

3.2.1  Operational .  Operational  computer  programs  provided  to  a  unit  of  the  operating 
forces  which  contribute  to  Che  performance  of  the  unit's  mission. 

3.2.2  Test  and  maintenance.  Programs  provided  to  the  user/operator  unit  of  the  oper¬ 
ating  forces  as  tools  to  assist  in  the  planned  maintenance,  fault  diagnosis  and  isolation, 
operational  readiness  verification  and  system  alignment  checkout  of  the  weapon  system  or 
its  components.  These  programs  may  be  used  to  check  out  and  certify  the  equipment  and 
total  system  at  installation,  re-installation  or  after  maintenance.  They  are  also  used 
periodically  in  accordance  with  prescribed  maintenance  procedures  to  maintain  the  system 
throughout  its  operational  life. 

3.2.3  Trainer .  Programs  utilized  to  train  crew,  operators  and  maintenance  forces  in 
the  operation  and  maintenance  of  the  weapon  system. 
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£.  Test  programs  used  in  weapon  system  software  development. 

3.3  Component ■  A  software  component  Is  a  subset  of  the  weapon  system  software.  Weapon 
system  software  can  be  hierarchically  broken  down  Into  components  of  program,  subprogram, 
module  and  procedure  or  routine.  A  program  refers  to  the  weapon  system  software  or  one 
independent  part  of  the  software  of  a  weapon  system,  depending  upon  the  complexity  of  any 
particular  weapon  system.  Subprogram  refers  to  a  major  functional  subset  of  a  program 
and  is  made  up  of  one  or  more  modules.  A  module  is  an  independently  compilable  software 
component.  Modules  are  comprised  of  one  or  more  procedures  or  routines. 

3.4  Development .  As  applied  to  the  life-cycle  of  weapon  system  software  in  this  stand¬ 
ard,  development  encompasses  the  span  of  time  and  effort  which  is  applied  to,  and  which 
results  in,  weapon  system  software  from  initiation  of  the  effort  through  delivery  and 
acceptance  by  Che  procuring  agency. 

3.4.1  Development  facility.  Within  Che  context  of  this  standard,  the  development 
facility  refers  to  the  physical  site  where  the  contractor  produces  the  weapon  system 
software. 

3.4.2  Procuring  agent/agency.  As  used  in  this  standard,  the  procuring  agent  or  agency 
refers  to  that  Government  office,  with  contract  and  project  directive  administration  auth¬ 
ority,  which  has  prime  responsibility  for  and  authority  over  the  development  effort. 

3.4.3  Program  manager.  As  used  in  this  standard,  the  program  manager  is  the  Govern¬ 
ment  official  designated  by  proper  authority  as  having  responsibility  for  the  develop¬ 
ment  of  the  weapon  system.  In  most  cases,  the  program  manager  and  the  procuring  agent 
are  one  and  the  same;  the  former  being  a  governmental  management  title  while  the  latter 
is  a  contractual  designation. 

3.4.4  Contractor.  As  used  in  this  standard,  contractor  refers  to  any  organization 
under  contract  or  tasking  arrangement  with  the  Government  to  perform  any  part  of  the 
weapon  system  development  effort. 

3.4.5  Development  monitor.  A  development  monitor  is  a  representative.  Government 
or  commercial,  of  the  program  manager  authorized  to  monitor  the  development  effort  in 
accordance  with  specific  terms  of  the  monitoring  task  or  contract. 

3.4.6  Test  facility.  As  used  in  this  standard,  the  test  facility  is  a  physical  loca¬ 
tion  designated  as  the  site  for  acceptance  testing  or  integration  testing  of  the  weapon 

system  software. 

3.5  Operational  support.  As  applied  to  the  life-cycle  of  weapon  system  software  in 
this  standard,  operational  support  encompasses  the  span  of  time  and  effort  from  accept¬ 
ance  for  operational  use  through  the  operational  life  of  the  system. 

3.5.1  Software  support  activity.  The  software  support  activity  is  that  organization 
designated  to  maintain  and  support  the  weapon  system  software  during  the  operational  sup¬ 
port  phase  of  the  life-cycle. 

3.6  Specifications.  Within  the  context  of  this  standard,  when  used  in  regard  to  weapon 
system  software,  specifications  are  documents  intended  to  describe,  clearly  and  accurately, 
the  essential  features  and  requirements  of  the  subject  computer  program.  Specifications 
are  categorized  into  four  types. 

3.6.1  Program  performance  specification.  The  program  performance  specification  de¬ 
scribes  the  technical,  operational,  and  performance  requirements  of  ths  weapon  system 
software  and  defines  and  specifies  all  the  functional  requirements,  pits  all  the  design 
constraints  and  standards  to  ensure  proper  development  and  maintenance  of  the  weapon 
system  software. 
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3.6.2  Program  design  specification.  The  program  design  specification  describes  the 
technical  design  of  the  weapon  system  software  necessary  to  implement  the  technical,  oper¬ 
ational,  performance,  and  functional  requirements  described  in  the  program  performance 
specification. 

3.6.3  Test  specification.  The  test  specification  describes  the  test  criteria  and  the 
methods  to  be  used  in  a  specific  test  to  assure  that  the  performance  and  design  speci¬ 
fications  have  been  satisfied.  The  test  specification  Identifies  the  capabilities  or 
program  functions  to  be  tested  and  identifies  the  test  environment. 

3.6.4  Interface  design  specification.  The  interface  design  specification  describes 
the  interdigital  processor  message  traffic  when  two  or  more  digital  systems  are  inter¬ 
faced  at  the  on-line  interdigital  processor  level. 

3.7  Baseline .  As  used  in  this  standard,  a  baseline  is  comprised  of  all  documents, 
program  materials,  and  the  development  support  library  which  make  up  the  complete  repre¬ 
sentation  of  the  weapon  system  software  at  a  specific  stage  of  its  development. 

3.8  Tactical  Data  Systems  Glossary.  Definitions  of  operational  and  technical  terms 
used  in  this  standard  in  regard  to  the  weapon  system  software  development  are  included 
In  references  2.1c,  d  and  e. 

3 . 9  Errors ■ 

3.9.1  Software  error.  An  occurrence,  during  the  execution  of  a  program,  attributable 
to  software  which  fails  to  satisfy  the  program  performance  specification  or  falls  to  per¬ 
form  as  designed. 

3.9.2  Documentation  error.  An  occurrence  in  the  documentation  which  fails  to  reflect 
the  operational  requirements  or  accurately  describe  or  support  the  software. 

3.9.3  Intermittent  error.  An  error  which  cannot  be  reproduced  consistently  when  the 
same  procedures  and  environment  are  duplicated. 

3.10  Software  Change  Proposal  (SCP) .  A  Software  Change  Proposal  (SCP)  is  a  proposed 
change  to  the  weapon  system  software  or  its  documentation  which  would  alter  the  approved 
baseline  software  or  documentation  which  is  under  configuration  control. 

3.11  Software  Trouble  Report  (STR).  A  Software  Trouble  Report  (STR)  is  a  report  that 
the  weapon  system  software  is  not  In  conformance  with  the  approved  baseline  documentat Ion 
which  is  under  configuration  control. 

3.12  Software  Enhancement  Proposal  (SEP).  A  Software  Enhancement  Proposal  (SEP'  Is  a 
proposed  change  to  the  weapon  system  software  or  its  documentation  or  its  Interfaces 
which  is  not  an  STR  or  SCP  and  is  functionally  transparent  to  all  portions  of  the  weapon 
system  that  are  not  directly  addressed  by  the  SEP. 

3.13  Use  of  "shall",  "will",  "should"  and  "may".  Within  the  context  of  this  Militarv 
Standard,  "shall"  is  used  to  express  a  provision  that  is  binding;  "should"  and  "mav"  are 
used  to  express  nonmandatory  provisions;  "will"  is  used  to  express  a  declaration  of  pur¬ 
pose  or  Intent. 

3.14  Reduced  capability  mode.  After  experiencing  the  loss  of  one  or  more  equipments 
or  equipment  parts,  system  operation  continues  in  a  configuration  which  compensates  for 
the  losses  but  at  a  level  below  system  designed  capability. 

3.15  Patch  (Low  level  language).  A  change  made  to  the  object  program  after  it  Is 
assembled  or  compiled. 

3.16  Program  stop.  A  program  stop  is  defined  as  any  termination  of  program  execution 
which  requires  that  the  program,  or  a  portion  thereof,  be  reloaded,  restarted,  or  re- 
ini  t  lall  zed  . 
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4 .  GENERAL  REQUIREMENTS 

4.1  Software  development,  management.  The  contractor  shall  plan  and  implement  proce¬ 
dures  to  control  the  development  process  and  provide  visibility  to  management  and  the 
Government  over  the  development  process.  The  contractor's  organization  shall  be  structu 
ed  to  provide  positive  control  over  development  processes  and  resources  utilized.  Weapo 
system  software  shall  be  subject  to  the  same  rigorous  discipline  that  is  normally  applie 
to  hardware  during  development. 

4.2  Design  requirements.  The  contractor  shall  determine  the  weapon  system  software 
design,  as  tasked  by  the  procuring  agency.  It  is  the  responsibility  of  the  contractor  t 
ensure  that  this  proposed  design  meets  the  program  performance  specifications.  The  de¬ 
sign  shall  completely  satisfy  all  requirements  but  shall  not  exceed  the  requirements 
without  procuring  agency  approval.  Design  complexity  and  the  interdependencies  of  sub¬ 
programs,  modules,  procedures  and  routines  shall  be  minimized. 

4.3  Program  generation.  Weapon  system  software  shall  be  coded  in  one  of  the  high  ord 

programming  languages  approved  for  use  by  the  Department  of  Defense  unless  a  spe¬ 

cific  waiver  has  been  previously  granted  to  the  procuring  agency  by  proper  authority. 

The  programs  shall  be  capable  of  being  generated  by  government  owned  support  software  am 
the  contractually  delivered  support  software. 

4.4  Quality  assurance.  The  contractor  shall  develop  and  implement  procedures  and  pra< 
tices  to  ensure  that  all  requirements  of  the  contract,  Including  this  Military  Standard 
as  contractually  invoked,  are  complied  with  fully.  The  quality  assurance  program  shall 
be  part  of  the  management  reporting  system  during  all  phases  of  software  development. 

The  contractor's  quality  assurance  program  shall  utilize  specification  reviews,  design 
reviews,  monitoring,  auditing,  and  testing  among  other  techniques  to  ensure  compliance 
with  contract  technical  requirements.  In  addition,  quality  control  procedures  shall  be 
used  to  examine  and  determine  compliance  with  requirements  in  order  to  ensure  that  con¬ 
tract  technical  and  performance  requirements  have  been  met. 

4.5  Configuration  management.  The  contractor  shall  establish  and  implement  the  dis¬ 
ciplines  of  configuration  management;  namely  configuration  identification,  configuration 
control,  and  configuration  status  accounting.  The  contractor  shall  be  cognizant  of  the 
requirement  for  long-term  life-cycle  support  of  the  weapon  system  software.  The  appro¬ 
priate  degree  of  configuration  management  shall  be  applied  to  ensure  completely  accurate 
correlation  between  descriptive  documentation  and  the  program  in  order  to  facilitate 
post-delivery  maintenance  by  software  support  personnel.  The  contractor  shall  plan  and 
implement  configuration  management  procedures  to  identify  software  elements  (configura¬ 
tion  items)  requiring  control,  to  define  and  control  change  implementation  processes,  to 
track  development  and  change  status,  and  to  ensure  documentation  is  changed  to  reflect 
current  status  of  the  software. 

This  standard  contains  the  contractor's  internal  configuration  management  requirements. 
These  shall  complement  the  contractor's  associated  requirements  for  interfacing  with  the 
procuring  agency  when  proposed  engineering  changes  affect  government  controlled  config¬ 
uration  identification.  This  interface  shall  be  in  accordance  with  appropriate  contract 
requirements  and  reference  2.1a  or  2.1b. 

4.6  Subcontractor  control.  The  contractor  is  responsible  for  assuring  that  all  soft¬ 
ware,  documentation  and  programming  materials  procured  from  his  subcontractors  conform 
to  the  contract  requirements.  Therefore,  this  Military  Standard  shall  be  Invoked  on  all 
subcontractors  involved  in  the  development  of  weapon  system  software. 

4.7  Deviations  and  waivers.  All  weapon  system  software  and  software  documentation 
thall  be  developed  and  delivered  in  exact  conformance  with  all  the  requirements  of  this 
Military  Standard,  other  applicable  standards,  and  applicable  weapon  system  software  do¬ 
cumentation  and  specifications,  as  contractually  Invoked  unless  a  deviation  or  waiver  has 
been  previously  processed  and  approved  by  the  procuring  agency  in  accordance  with  refer¬ 
ence  2.1a  or  .‘.ib.  The  extent  cf  anv  variance  from  exact  conformance  to  all  applicable 
requirements  snail  only  be  that  which  is  specifically  authorized  bv  formally  approved 
deviations  or  waivers. 
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5.  DETAILED  REQUIREMENTS 


5.1  Program  performance  requirements.  The  contractor  shall  determine  the  detailed 
program  performance  requirements  for  the  weapon  system  software.  The  contractor  shall 
utilize  the  basic  descriptive  requirements  and  design  information  provided  by  the  pro¬ 
curing  agency  to  create  the  program  performance  requirements.  This  information  may  be 
augmented  by  studies,  analyses,  visits  to  operational  units,  and  surveys  as  necessary. 

The  program  performance  requirements  are  subject  to  the  review  and  approval  of  the  pro¬ 
curing  agent. 

5.1.1  Supporting  information  for  program  performance  requirements.  The  contractor 
shall  utilize,  as  a  minimum,  those  items  available  of  the  following  to  determine  the 
program  performance  requirements: 

a.  System  performance  requirements. 

b.  System  design  specifications. 

c.  Equipment  design  specifications. 

d.  Interface  design  specifications. 

e.  Operational  standards,  doctrine,  and  tactics. 

f.  System  design  standards. 

5.1.2  Computer  program  performance  analysis.  In  determining  the  performance  require¬ 
ments,  the  contractor  shall  investigate  and  analyze  in  detail  all  areas  relating  to  the 
performance  requirements  of  the  weapon  system  software. 

5. 1.2.1  Mission  areas.  The  contractor  shall  investigate  the  mission  areas,  primary 
and  secondary,  and  supporting  tasks  of  the  operational  user  or  platform  for  the  weapon 
system. 

5. 1.2. 2  Functions ■  The  contractor  shall  define  the  major  functions  or  groupings  of 
the  program  necessary  to  meet  the  system  performance  requirements. 

5. 1.2. 3  Applicable  documentation  for  program  performance  requirements.  The  contractor 
shall  Identify  all  documents  which  define  or  constrain  the  program  performance  require¬ 
ments.  Definitions  of  applicable  terms  and  abbreviations  not  consistent  with  or  not  in¬ 
cluded  in  reference  document  2.1c  shall  be  indicated  and  defined  by  the  contractor. 

5. 1.2. 9  Weapon  system  description.  The  contractor  shall  examine  the  relationship  of 
all  components  in  the  weapon  system  which  affect  the  weapon  system  software  or  the  pro¬ 
gram  performance  requirements.  The  contractor  shall  determine  how  the  computer  program 
interfaces  with  other  components  to  perform  required  functions. 

a.  Peripheral  equipment  identification.  The  contractor  shall  identify  all  equip¬ 
ment  with  which  the  program  will  interface. 

b.  Interface  identification.  The  contractor  shall  identify  all  other  digital 
programs  or  systems  with  which  the  program  will  interface. 

5. 1.2. 5  Functional  description.  The  contractor  shall  analyze  the  major  functions  and 
the  functional  relationships  of  the  program  with  interfacing  equipments  and  other  pro¬ 
grams  . 

a.  Equipment  descriptions.  The  contractor  shall  identify  the  requirements  imposed 
on  the  program  by  each  interfacing  equipment,  the  purpose  of  the  equipment,  and 
the  use  of  options  and  controls. 
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b.  Block  diagrams.  The  contractor  shall  generate  diagrams  of  equipment  and  program 
relationships  with  internal  and  external  data  flow. 

c.  Intersystem  Interface.  The  contractor  shall  determine  the  interfaces  with  other 
systems  and  shall  be  cognizant  of  the  performance  requirements  and  design  speci¬ 
fications  of  all  systems  which  will  interface  with  the  system  under  development. 
Each  contractor  shall  be  aware  of  the  purpose  of  the  interface  and  the  data  to 
be  exchanged.  Data  quantity,  frequency,  rate,  format,  content,  scaling  require¬ 
ments  and  conventions  shall  be  developed.  In  fulfilling  this  assignment,  the 
contractor  may  be  tasked  to  participate  with  other  development  contractors  as  a 
team  to  design  the  Intersystem  interfaces  so  that  the  performance  requirements 
of  all  systems  are  met.  If  Interface  conflicts  are  uncovered  such  that  an  in¬ 
dividual  system's  ability  to  perform  in  accordance  with  its  requirements  is  ad¬ 
versely  affected,  the  interface  design  team  shall  recommend  to  the  procuring 
agency  the  necessary  modifications  to  the  systems  or  their  interface  to  over¬ 
come  the  deficiency.  If  no  solution  can  be  agreed  upon,  the  team  shall  recom¬ 
mend  modification  of  the  system  performance  requirements  to  the  procuring  agenc. 

d.  Function  description.  The  contractor  shall  establish  the  performance  of  each 
function  supported  by  the  program,  its  purpose,  and  functional  design. 

5. 1.2.6  Detailed  functional  requirement.  The  contractor  shall  delineate  the  perform¬ 
ance  of  each  function  by  detailing  its  narrative,  logical,  and  mathematical  descriptions. 

a.  Inputs.  The  contractor  shall  define  all  inputs  (external  and  internal)  Including 
their  source,  format,  method  of  reception,  quantity,  timing,  range,  and  scaling. 

b.  Processing.  The  contractor  shall  generate  textual  and,  as  appropriate,  mathe¬ 
matical  descriptions  of  the  processing  requirements  of  each  function,  including 
functional  parameters  and  geometric  diagrams. 

c.  Outputs.  The  contractor  shall  define  all  outputs  (internal  and  external)  in¬ 
cluding  their  method  of  transmission  and  timing,  meaning,  format,  destinations, 
range,  and  scaling. 

d.  Special  requirements.  The  contractor  shall  Identify  all  requirements  imposed  by 
higher-level  constraints  or  by  exigencies  of  the  function. 

5. 1.2. 7  Adaptive  parameters.  The  contractor  shall  Identify  those  parameters  which  re¬ 
flect  the  system  environment,  system  parameters,  and  system  capacities  and  which  can  be 
modified  without  altering  the  logic  of  the  operational  function. 

5.1.3  System  resources.  The  contractor  shall  define  the  computer  memory,  computer 
processing  time,  and  input  and  output  resource  budgets  and  their  projected  utilization 
for  the  weapon  system.  If  the  weapon  system  under  development  has  more  chan  one  digital 
processor,  the  contractor  shall  define  these  resource  values  for  each  digital  processor. 

5.2  Program  design  requirements.  The  contractor  shall  develop  the  detailed  program 
design  requirements  in  accordance  with  the  detailed  program  performance  requirements  ap¬ 
proved  by  the  procuring  agency  and  shall  comply  with  other  design  constraints  and  stand¬ 
ards  as  specified  by  the  procuring  agency.  The  requirements  shall  be  translated  into  pro¬ 
gram  design  in  a  systematic  top-down  method.  The  design  shall  be  a  hierarchical  struc¬ 
ture  of  identifiable  programs,  subprograms,  modules,  procedures,  and  routines.  The 
highest  level  of  control  logic  resides  at  the  top  of  the  hierarchy;  the  computational  or 
algorithmic  functions  reside  at  the  lower  levels.  The  program  shall  be  divided  into  con¬ 
stituent  parts  and  then  these  parts  broken  down  into  their  constituents.  Each  level  of 
design  development  (or  breakdown)  is  continued  until  a  level  is  reached  where  there  is  no 
subservient  level.  Levels  shall  be  structured  so  that  a  lower  level  does  not  call  on  a 
higher  level . 
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The  contractor  9hall  define  the  assumptions,  the  programming  approach  for  implementing 
the  computer  program  and  shall  define  the  program  architecture.  As  early  as  possible  in 
the  design  phase,  the  proposed  program  architecture  shall  be  verified  as  to  its  capability 
to  support  the  computational  load  imposed  by  maximum  operation  of  all  functions  required 
to  be  simultaneously  serviced.  This  verification  may  require  extensive  modeling  and 
simulation  and  shall,  in  all  cases,  be  completed  prior  to  design  Implementation  and 
coding . 

The  program  design  shall  be  subject  to  review  and  approval  by  the  procuring  agency.  Prior 
to  submission  of  the  detailed  design  to  the  procuring  agency  for  review,  a  design  walk¬ 
through  shall  be  conducted.  This  design  walk-through  shall  be  accomplished  by  one  or  more 
technically  qualified  persons  in  conjunction  with  the  originator  or  originators  of  the 
detailed  design. 

5.2.1  Supporting  information  for  program  design  requirements.  The  contractor  shall 
utilize,  as  a  minimum,  those  items  available  of  the  following  to  determine  the  program 
design: 

a.  System  operational  design  documents. 

b.  Program  performance  specifications. 

c.  Interface  design  specifications. 

d.  Programming  reference  manuals. 

e.  Equipment  technical  manuals. 

f.  Specified  programming  standards  and  conventions. 

g.  Specified  utility/support  software  documents. 

5.2.2  Computer  program  design  analysis.  In  determining  the  detailed  computer  program 
design,  the  contractor  shall  investigate  and  analyze  in  detail  the  following  areas  re¬ 
lating  to  the  computer  program. 

5.2.2. 1  Applicable  documentation  for  program  design  requirements.  All  documents  which 
constrain,  define,  or  Influence  the  program  design  shall  be  analyzed.  The  contractor 
shall  define  all  design  terms  and  abbreviations  used  to  describe  the  program  design. 

5. 2. 2. 2  Functional  allocation.  The  allocation  of  functions  and  tasks  to  be  performed 
by  the  subprograms  and  their  modules  shall  be  defined.  All  performance  requirements  shall 
be  satisfied  in  their  entirety  in  this  allocation. 

5. 2. 2. 3  Program  functional  flow.  The  flow  of  program  data  and  control  in  all  required 
modes  of  program  operation  shall  be  determined.  A  functional  description  of  all  Inputs, 
outputs  and  processing  for  each  subprogram  shall  be  defined. 

a.  Program  interrupt  control.  The  source,  purpose,  type,  predicted  rate  of  occur¬ 
rence,  and  required  control  response  for  each  external  and  internal  Interrupt 
shall  be  determined  from  the  analysis. 

b.  Subprogram  reference  control.  The  control  logic,  assignment  of  priorities  and 
permissible  cy^'e  times  for  each  subprogram  shall  be  determined  from  the 
analysis. 

c.  Special  control  features.  Unique  control  requirements  which  affect  the  design 
of  the  control  logic  shall  be  identified. 

5. 2. 2.4  Resource  allocation  and  reserves.  Memory  storage,  input  and  output  channels, 
and  processing  time  requirements  for  each  subprogram  3hall  be  determined.  Total  system 
memory,  input  and  output  channels,  and  processing  time  reserves  of  at  least  20  percent 
shall  exist  at  the  time  of  program  acceptance  by  the  procuring  agency. 
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5. 2. 2. 5  Design  constraints.  The  constraints  of  the  specific  programming  language  to 
be  used  and  the  constraints  of  the  specific  support  software  to  be  used  shall  be  defined 
by  the  contractor. 

5. 2. 2. 6  Data  base  design.  During  the  computer  program  design,  the  contractor 
take  into  account  all  data  used  by  two  or  more  subprograms. 

5.2.3  Intersystem  interface.  The  contractor  shall  determine  the  interfaces  with  other 
systems  and  shall  be  cognizant  of  the  performance  requirements  and  design  specifications 
of  all  systems  which  will  interface  with  the  system  under  development.  Each  contractor 
shall  be  aware  of  the  purpose  of  the  interface  and  the  data  to  be  exchanged.  Data  quanti¬ 
ty,  frequency,  rate,  format,  content,  scaling  requi •. ements ,  and  conventions  shall  be  de¬ 
veloped.  In  fulfilling  this  assignment,  the  contractor  may  be  tasked  to  participate  with 
other  development  contractors  as  a  team  to  design  the  intersystem  interfaces  so-  that  the 
performance  requirements  of  all  systems  are  met.  If  interface  conflicts  are  uncovered 
such  that  an  individual  system's  ability  to  perform  in  accordance  with  its  requirements 

is  adversely  affected,  the  interface  design  team  shall  recommend  to  the  procuring  agency 
the  necessary  modifications  to  the  systems  or  their  interface  to  overcome  the  deficiency. 

If  no  solucion  can  be  agreed  upon,  the  team  shall  recommend  modification  of  the  system 
performance  requirements  to  the  procuring  agent. 

5.3  Programming  standards ■  The  following  design  and  coding  standards  shall  apply  to 
the  development  of  weapon  system  software. 

5.3.1  Control  structures.  Programs  should  be  designed  and  shall  be  coded  using  only  the 
five  basic  control  structures  presented  in  figures  1A  -  IE.  They  are:  the  SEQUENCE  of  op¬ 
erations  (assignment,  add,...),  IF  THEN  ELSE  (conditional  branch  to  one  of  two  operations 
and  return) ,  DO  WHILE  (operation  repeated  while  a  condition  is  true) ,  DO  UNTIL  (operation 
repeated  until  a  condition  is  true)  and  CASE  (operation  which  provides  the  transfer  of 
program  control  to  a  specific  location  within  a  compile-time  system).  Structured  programs 
of  any  degree  of  complexity  can  be  developed  if  they  can  be  broken  down  into  individual 
control  structures. 

5.3.2  Included /cop led  segments.  Included/copied  segments  shall  be  written  in  HOL  only, 
unless  a  specific  waiver  has  been  previously  granted  to  the  procuring  agency  by  proper 
authority.  Any  program  logic  within  a  given  structural  segment  shall  utilize  only  those 
control  structures  specified  in  paragraph  5.3.1.  When  the  segment  contains  executable 
statements,  the  entry  to  the  segment  shall  be  the  first  executable  statement  and  the  exit 
shall  be  the  last  executable  statement. 

5.3.3  Entry-exit  structure.  Each  module,  procedure,  routine,  or  source  code  segment 
shall  have  a  single  entry  and  single  exit  structure.  (See  figure  IF) 

5.3.4  Program  traceability.  Programs  shall  be  designed  and  coded  such  that  upon  inter¬ 
rupt  or  termination,  the  values  of  the  various  parameters,  Indices  and  other  local  vari¬ 
ables  as  of  the  last  usage  are  recoverable. 

5.3.5  Self -modification.  Program  self-modification  of  instructions  during  execution 
shall  be  prohibited. 

5.3.6  Recursive  programs.  Recursive  procedures  or  routines  shall  noc  be  used  unless 
Che  target  computer  has  a  stack  oriented  architecture. 

5.3.7  Size.  The  procedures  or  routines  which  make  up  a  module  shall  noc  exceed  an 
average  of  one  hundered  executable  HOL  statements  per  procedure  or  routine  and  shall  not 
exr >ed  a  maximum  of  two  hundred  executable  statements  in  any  procedure  or  routine.  Each 
independently  executable  HOL  statement,  whether  free-standing,  part  of  a  complex  statement 
or  in  an  Included /cop led  segment  counts  as  one  executable  statement. 

5.3.8  Branching.  Branching  statements  (GO  TO's)  may  be  used  only  with  the  approval 
of  the  procuring  agency.  Branching  statements,  if  approved,  shall  only  pass  control  to 
a  statement  chat  is  in  the  same  procedure  or  routine.  Each  GO  TO  must  pass  control  only 
forward  of  its  point  of  occurrence.  (Backward  Jumps  generated  by  the  compiler  are  per¬ 
mitted)  . 


ENTER 


A 


B 


EXIT 


Control  flows  fron  procsss  A  to  ths  nut  In  sequence,  process  B. 


FIGURE  13. 

IF  THEN  ELSE:  If  condition  A  THEN  procsss  B,  ELSE  process  C. 


Ths  flow  of  control  will  return  to  s  coaon  point  sfter  executing  either  process  B  or  C. 

A  predlcetes  the  conditional  execution.  If  control  is  to  skip  a  process  pending  the  con** 
dltlon  of  A,  then  the  flow  chart  can  be  modified  thusly: 


FXGUM  1.  Control  structures. 
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FIGURE  1C.  DO  WHILE:  DO  WHILE  condition  A.  process  B 


The  DO  WHILE  structure  Is  •  loop  In  which  the  condition  A  is  evaluated.  If  found  to  be 
true,  than  control  is  passed  to  process  B  and  the  condition  A  is  evaluated  again.  If  con¬ 
dition  A  is  false,  then  control  is  passed  out  of  the  loop. 


FIGURE  ID.  DO  UNTIL:  DO  UNTIL  condition  A,  Process  B. 


The  DO  UNTIL  structure  is  similar  to  the  DO  WHILE  —  except  that  the  test  of  condition  A 
is  performed  after  process  B  has  executed.  Thua  the  DO  UNTIL  loop  will  be  performed  once 
regardless  of  the  value  of  condition  A. 


FIGURE  IE.  CASE:  Based  on  Case  conditional  1,  process  1. 


Control  Is  passed  to  procass  k  based  on  the  value  of  1. 

FIGURE  1.  Control  structures  (continued) 
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5.3.9  Relocatabillty .  Programs  shall  be  built  in  the  form  of  relocatable  object  mod¬ 
ules  . 


5.3.10  Indentation ■  Program  structural  indentation  shall  be  used  to  Improve  readabil¬ 
ity  and  clarity. 

5.4  Programing  conventions.  The  following  programming  conventions  shall  be  utilized 
In  all  weapon  system  software. 

5.4.1  Symbolic  parameterization.  All  values  used  in  the  weapon  system  software  which 
are  constant  throughout  the  weapon  system  design  but  which  may  be  affected  by  environment 
changes  (e.g.,  sensor  output  limits,  maximum  range  of  weapons,  maximum  number  of  targets 
handled,  data  storage  limits)  shall  be  treated  as  symbolic  parameters  In  the  design. 
Duplication  of  symbolic  parameters  shall  be  minimized  through  use  of  common  source  of 
values.  When  duplication  is  necessary,  common  symbolic  parameter  identification  nomencla¬ 
ture  shall  be  used  and  comments  will  point  to  location  of  duplicates.  Symbolic  para¬ 
meters  shall  be  grouped  at  the  beginning  of  each  subprogram.  Comments  shall  provide  a 
definition  and  the  location  of  all  parameters.  Special  symbolic  parametric  definition 
features  of  the  high  level  language  and  compiler  shall  ue  used. 

5.4.2  Naming.  Naming  conventions  shall  be  uniform  throughout  the  weapon  system  soft¬ 
ware.  Program,  subprogram,  module,  procedure,  routine  and  data  names  shall  be  uniquely 
chosen  to  identify  the  applicable  function  performed  and  their  position  in  the  hier¬ 
archical  logic  structure  in  relation  to  other  components  of  the  weapon  system  software 
being  developed. 

5.4.3  Numerical  conventions.  Numerical  conventions  shall  be  established  by  the  con¬ 
tractor  so  chat  they  are  uniform  throughout  the  program. 

5. 4. 3.1  Symbolic  conscants  and  variables.  Constants  and  variables  entering  into  nu¬ 
merical  computations  shall  follow  the  constraints  set  forth  in  paragraph  5.4.1. 

5. 4. 3. 2  Mixed  mode  expression.  Mixed  mode  numerical  operations  shall  be  avoided  when¬ 
ever  possible,  but  when  determined  to  be  necessary,  they  shall  be  completely  descrioed 
.In  comments. 

5. 4. 3. 3  Grouping.  Parentheses  or  other  subexpression  delimiters  shall  be  used  where 
necessary  to  clarify  the  order  of  evaluation  of  compound  expressions. 

5. 4. 3. 4  Significant  digits.  The  number  of  significant  digits  as  output  shall  not  be 
greater  than  the  number  of  significant  digits  as  input.  The  effect  of  truncation  per¬ 
formed  shall  be  considered  in  applying  this  convention.  Sufficient  significant  digits 
shall  be  used  in  calculations  to  yield  a  minimum  of  computational  error,  and  rounding  by 
the  programmer  shall  not  occur  until  the  final  computational  step.  The  degree  of  compu¬ 
tational  error  shall  be  analyzed  to  determine  if  systems  accuracy  requirements  are  ful¬ 
filled. 

5.4.4  Narrative  description.  A  narrative  description  shall  describe  the  history  and 
identify  the  functions  of  each  hierarchical  component  of  the  weapon  system  software. 

5.4.4. 1  Abstracts.  Each  component  shall  include  at  the  beginning  of  the  executable 
coding  a  textual  description  of  its  Inputs,  outputs,  function  or  task,  and  algorithms; 
a  list  of  ocher  components  called;  and  a  list  of  all  calling  components.  In  addition 
to  general  explanations,  to  assist  understanding,  precise  references  to  the  appropriate 
statement  labels  and  data-names  shall  be  Included  in  each  module,  procedure  and  routine 
descriptive  abstract.  The  descriptive  abstract  shall  define  the  allowed  and  colerablc 
range  of  values  for  all  inputs  and  shall  define  the  allowed  and  expected  range  of  values 
for  all  outputs.  A  history  of  the  original  and  updating  programmer  names,  the  activity  or 
commercial  company  name  and  the  activity  or  company  division  code  or  billet  identifier 
with  daces  completed  shall  be  included. 

5. 4. 4. 2  Comment  statements.  In  order  to  facilitate  program  comprehension,  comment 
statements  shall  be  used  throughout  the  program  code.  Comment  statements  are  non-exe- 
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cutable  (i.e.,  they  have  no  effect  on  program  executions)  and  are  used  to  provide 
documentation  and  clarification  of  the  logic,  data,  variables,  and  algorithms.  Each 
source  statement  shall  be  self-defined  or  defined  by  a  comment  phrase  to  a  level  under¬ 
standable  by  a  person  not  associated  with  the  original  development  effort.  Logical 
groups  of  comment  phrases  may  be  included  in  a  single  comment  statement.  General  comments 
on  groups  of  source  statements  performing  logical  functions  shall  be  Included  on  separate 
comment  statements. 

5.4.5  Source  record  format. 

5. 4. 5.1  Execution  efficiency.  Subject  only  to  the  interest  of  readability,  clarity 
and  maintainability,  source  statements  shall  be  optimized  for  execution  efficiency.  For 
maximum  memory  efficiency,  common  routines  or  procedures  should  be  used  Instead  of  in¬ 
cluded/  cop  led  source  code  blocks  whenever  practicable. 

5. 4. 5. 2  Source  code  segment  Includes/copy.  When  repetitive  segments  of  source  code 
are  required  in  the  program  being  developed,  they  should  be  coded  only  once  as  a  struc¬ 
tural  source  code  block,  thereafter  being  referenced/utilized  upon  each  occurrence  by 
appropriate  INCLUDES  or  COPY  features,  or  constructs  of  the  source  HOL  compiler. 

5. 4. 5. 3  Source  statement .  A  source  statement  shall  not  be  compound  or  complex  in 
structure  except  as  necessary  to  support  the  control  structures  defined  in  paragraph  5.3.1. 

5.4.6  Flow  charts.  There  i9  no  requirement  that  flow  charts  be  a  deliverable  item. 

5.5  Program  production.  The  contractor  shall  generate  the  program  in  a  top-down, 
well-controlled  manner.  Top-down  implementation  requires  that  units  of  code  that  depend 
on  the  operation  of  other  units  be  developed  after  the  unit  upon  which  they  depend.  Pro¬ 
gramming  shall  commence  with  the  highest  levels  which  shall  then  be  tested  extensively 
and  placed  under  configuration  management  and  library  control  before  descending  downward 
in  the  design  to  the  programming  of  subordinate  levels.  This  methodology  will  permit 
orderly  integration  of  units  of  code  into  an  evolving  computer  program.  Incremental  de¬ 
velopment  of  software  will  result  which  allows  for  well-controlled  incremental  testing 
where  the  higher  control  structures  are  tested  most  often. 

Programming  conventions,  program  design  rules  and  programming  standards  shall  be  promul¬ 
gated  to  and  followed  by  all  levels  of  program  production  personnel.  The  contractor  shall 
ensure  programmers  are  skilled  in  the  use  of  the  specified  language  and  compiler  ca,  '-il- 
ities.  Standard  procedures  shall  be  developed  for  programmers  to  follow  in  use  of  couung 
forms,  submission  of  compile  requests,  reports  of  progress  and  associated  listings. 
Efficient  and  effective  control  of  the  program  during  coding  and  test  is  required. 

A  code  walk-through  review  of  each  program  component  shall  be  conducted  prior  to  sub¬ 
mission  of  the  component  for  compilation.  This  review  shall  be  conducted  by  one  or  more 
technically  qualified  persons  in  conjunction  with  the  originator  of  the  code  under  re¬ 
view. 


5.5.1  Program  production  organization.  The  contractor  shall  implement  a  program  pro¬ 
duction  organization  that  facilitates  the  top-down  design,  coding,  integration,  and 
testing  of  the  program. 

5.5.2  Resource  management.  The  contractor  shall  be  responsible  for  management  of 
computer  system  resources  (e.g.,  main  memory,  mass  storage,  processor  time,  input/output 
controller(s) ,  and  Input/output  channel(s)).  He  shall  determine  the  original  assignment 
of  system  resources  through  analysis  and  modeling.  The  contractor  shall  monitor  the  util¬ 
ization  of  the  assigned  resources  as  program  development  progresses.  A  minimum  reserve 

of  20  percent  capacity  shall  exist  in  each  resource  area  at  che  time  of  program  accept¬ 
ance  by  the  procuring  agency. 

5.5.3  Language ■  Weapon  system  software  shall  be  coded  in  one  of  the  high  order  pro¬ 
gramming  languages  (HOLs)  approved  by  the  Department  of  Defense  unless  a  specific  waiver 
has  been  previously  granted  to  the  procuring  agency  bv  proper  authority. 
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5.5.4  Library  usage  and  control.  The  contractor  shall  establish  procedures  for  pro¬ 
ducing,  updating  and  controlling  source  and  object  libraries  of  the  software  under  devel¬ 
opment.  All  initial  programs  and  development  changes  shall  be  maintained  in  both  source 
and  object  format.  All  patches  shall  be  maintained  in  maintenance  and  patch  logs  and 

on  patch  tapes  until  Incorporated  in  the  patch-free  source  program.  Patches  shall,  as  a 
minimum,  be  Identified  by:  patch  production  date,  programmer  producing  the  patch,  the 
program  component  chat  the  patch  Is  applicable  to,  the  corresponding  problem  number  or 
identification,  the  test  chat  revealed  the  problem,  the  testing  chat  certifies  the  integ¬ 
rity  of  the  patch,  and  the  problem  that  necessitated  the  patch. 

5.5.5  Sequence  numbering.  Each  source  record  in  each  smallest  independently  compilable 
unit  of  code  shall  contain  a  sequence  number  so  chat  it  can  be  uniquely  identified.  Se¬ 
quence  numbers  shall  be  in  sequentially  increasing  order  beginning  with  and  differing  by 
some  multiple  of  ten. 

5.5.6  Listings ■  Listings  related  to  the  program  shall  meet  the  standards  specified 
herein . 

5. 5.6.1  Program  listings.  For  acceptance  as  a  deliveraole,  the  listing  of  a  compiled 
program  shall  Include  source  language  statements  and  comments  with  resulting  object  ma¬ 
chine  instructions  interspersed  appropriately  (together  with  actual  or  equivalent  assem¬ 
bler  statements,  if  available).  Relative  location  of  instructions  and  operands  shall  be 
exhibited  together  with  statement  labels  and  identification  numbers.  All  descriptions 
of  referenced  procedures,  routines  and  data  shall  be  included  in  conjunction  with  this 
listing  and  arranged  for  convenient  access. 

5. 5.6. 2  Cross-reference  listing.  A  cross-ref erence  listing  shall  be  produced  relating 
each  data  name  to  the  location  of  every  other  statement  referring  to  it,  and  relating 
each  routine  to  the  location  of  every  other  routine  calling  upon  it.  The  list  shall  be 
exhibited  as  a  sequential  table  in  alphanumeric  order. 

5.5.7  Load  maps.  The  contractor  shall  describe  the  format,  method  and  location  in 
which  the  various  components  and  portions  thereof  are  loaded  in  the  weapon  system  com¬ 
puters  and,  if  applicable,  stored  on  disks  or  other  storage  devices.  This  mapping  shall 
include  delineating  all  of  the  portions  of  the  program  that  are  to  be  concurrently  resi¬ 
dent  in  the  device  in  question  and  the  locacion  and  size  of  each  portion  of  the  program. 

If  che  system  has  more  than  one  defined  configuration  or  mode  of  operation  for  Che  soft¬ 
ware,  the  contractor  shall  describe  this  Information  for  each  configuration  or  mode. 

5.6  Program  regeneration.  All  weapon  system  software  delivered  by  the  contractor  shall 
be  capable  of  being  regenerated  from  Government  owned  support  software  and  the  contractu¬ 
ally  delivered  support  software. 

5.7  Program  operation.  The  contractor  shall  determine  the  procedures  for  the  opera¬ 
tion  of  the  weapon  system  software.  Procedures  shall  be  described  in  terms  understandable 
to  operational  personnel.  Program  operation  procedures  shall  be  subject  to  the  approval 
of  the  procuring  agency. 

5.7.1  Program  operation  analysis.  In  determining  program  operation  procedures,  the 
contractor  shall  investigate  and  define  in  detail  the  following  areas. 

5. 7.1.1  Non-functional  operation.  Minimal  processor  and  peripheral  equipment  require¬ 
ments,  equipment  set-up  for  system  operation,  program  set-up,  special  parameter  entering 
requirements,  standby/operace  procedures,  monitoring  procedures,  and  recovery  procedures 
shall  be  defined. 

5. 7. 1.2  Functional  operation.  Individual  operator  and  station  functions;  coordinated 
station  procedures;  all  human  factor  aspects,  modes  and  procedures  necessary  for  each 
console  or  station  operator  to  perform  his  function  in  support  of  system  operation;  the 
function  of  every  control  button,  switch,  readout  and  display  affected  by  or  affecting 
the  system;  and  all  constraints  imposed  on  operator  actions  shall  be  defined. 
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5.8  Program  test.  The  contractor  shall  determine  the  scope  of  tests  required  to  ensure 
that  the  program  being  developed  meets  all  specified  technical,  operational,  and  perform¬ 
ance  requirements  and  the  acceptance  criteria.  The  contractor  shall  be  responsible  for 
accomplishing  all  development  testing.  Test  planning  shall  include  development  of: 

a.  Program  acceptance  criteria. 

b.  Levels  of  testing  to  verify  performance. 

c.  Internal  procedures  for  scheduling  and  conducting  tests. 

d.  Detailed  procedures  for  testing  at  each  level. 

e.  Reporting  procedures  of  test  results. 

All  test  plans,  specifications,  and  procedures  shall  be  subject  to  review  and  approval  by 
the  procuring  agency.  The  procuring  agency  shall  be  kept  advised  of  all  test  schedules 
and  shall  be  permitted  to  witness  all  tests  with  designated  Government  or  contractor  re¬ 
presentatives.  The  contractor  shall  provide  all  supporting  software  necessary  to  conduct, 
control,  and  record  tests.  The  contractor  shall  define  any  special  support  software 
necessary  to  satisfactorily  test  the  software  being  developed.  The  contractor  shall 
Identify  to  the  procuring  agency  any  GFE  or  GFI  required  to  support  the  test  program  early 
enough  to  allow  the  procuring  agency  to  obtain  and  deliver  any  such  requirements  without 
Impacting  the  development  and  testing  schedule. 

The  contractor  shall  provide  or  ensure  the  availability  of  adequate  facilities  for  con¬ 
ducting  all  required  tests.  The  procuring  agency  shall  have  the  option  of  specifying  the 
facility  that  should  be  used  to  conduct  any  portion  of  the  test  program. 

The  contractor  shall  prepare  test  reports  showing  quantitative  results  of  all  tests. 

Such  reports  shall  be  signed  by  a  representative  of  the  contractor.  Any  formal  or  in¬ 
formal  approval  of  the  testing  results  by  the  procuring  agency  representative  during  the 
course  of  software  production  shall  not  be  construed  as  a  guarantee  of  the  acceptance  of 
the  finished  product.  Testing  shall  consist  of  the  following: 

a.  Module  tests. 

b.  Subprogram  tests. 

c.  Program  performance  tests. 

d.  System(s)  integration  tests  . 

5.8.1  Module  tests.  Each  module  shall  have  completed  a  code  walk-through  prior  to 
being  subjected  co  developmental  testing.  Developmental  testing  shall  be  adequate  to  de¬ 
termine  compliance  with  the  applicable  technical,  operational  and  performance  specifica¬ 
tions.  As  a  minimum,  module  testing  shall  be  performed  to: 

a.  Ensure  error-free  compile/assembly  of  the  coded  module. 

b.  Ensure  Chat  the  coded  module  fully  satisfies  the  detailed  performance  md  de¬ 
sign  requirements  and  chat  all  code  to  be  delivered  has  been  exercised. 

c.  Exercise  the  module  In  terms  of  lnput/output  performance  with  the  results  satis¬ 
fying  Che  applicable  detailed  performance  and  design  requirements. 

5-8.2  Subprogram  tests.  Modules  shall  have  passed  the  module  tests  prior  to  being  sub¬ 
jected  to  subprogram  testing.  The  modules  shall  be  integrated  individually  into  particu¬ 
lar  subprograms.  Subprogram  tests  shall  be  adequate  to  determine  compliance  with  the 
applicable  technical,  operational  and  performance  requirements.  As  a  minimum,  subprogram 
testing  shall  be  performed  to: 

a.  Ensure  error-free  linkage  of  the  modules. 
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b.  Ensure  that  Che  subprogram  fully  satisfies  the  detailed  performance  and  design 
requirements . 

c.  Exercise  the  subprogram  in  terms  of  lnput/outpuc  performance  with  the  results 
satisfying  Che  applicable  detailed  performance  and  design  requirements. 

d.  Ensure  the  subprogram  level  man-machine  interfaces. 

e.  Ensure  the  capability  of  the  subprogram  to  handle  properly  and  survive  erroneous 
Inputs . 


5.8.3  Program  performance  tests.  All  subprograms  shall  have  passed  the  subprogram 
tests  prior  to  program  performance  testing.  the  subprograms  shall  be  integrated  individ¬ 
ually  until  all  subprograms  have  been  integrated  into  the  program.  These  tests  shall  be 
adequate  to  determine  compliance  with  the  applicable  technical,  operational  and  perform¬ 


ance  requirements.  As  a  minimum,  program  performance  testing  shall  be  performed  to: 


a.  Ensure  the  total  man-machine  interface. 


b.  Ensure  proper  system  initiation,  data  entries  via  peripheral  devices,  program 
loading,  restarting,  and  the  monitoring  and  controlling  of  system  operation 
from  display  consoles  and  other  control  stations  as  applicable. 

c.  Ensure  the  proper  Interfacing  of  all  equipment  specified  in  Che  program  perform¬ 
ance  requirements. 

d.  Ensure  the  capability  of  the  program  to  satisfy  all  applicable  system  and  pro¬ 
gram  performance  requirements. 

e.  Ensure  the  capability  of  the  system  to  handle  properly  and  survive  erroneous 
inputs . 

5.8.4  Svstem(s)  Integration  test.  In  instances  where  the  developed  program  is  an 
element  of  a  larger  system  Involving  the  integration  of  two  or  more  programs,  the  con- 
tractor(s)  shall  be  required  to  participate  in  total  system  integration  testing.  Inte¬ 
gration  tesclng  may  be  conducted  at  facilities  other  than  the  development  facility,  such 
as  a  land-based  test  sice.  Each  contractor  shall  provide  technical  support  to  the  In¬ 
tegration  tesclng  as  required. 

5.8.5  Software  trouble  reporting.  The  contractor  3hall  develop  and  implement  internal 
procedures  for  handling  and  reporting  all  software  or  software  related  problems  identi¬ 
fied.  In  addition  to  the  categories  and  priorities  described  below,  a  code  shall  be  util¬ 
ized  Co  indicate  the  status  of  each  Software  Trouble  Report  fSTR)  as  it  progresses  through 
the  correction  cycle.  All  STRs  shall  be  verified  for  accuracy  and  correctness  and  sub¬ 
mitted  on  standard  forms. 


The  contractor  shall  malncaln  a  complete  set  of  software  problem  data  files  throughout 
the  duration  of  the  contract  and  make  this  information  available  to  the  procuring  agency 
or  its  authorized  representative  upon  request. 

5. 8. 5.1  Software  trouble  report  category.  Software  problems  shall  be  classified  by 
category  as  follows: 

a.  Software  trouble  IS).  The  software  does  not  operate  according  to  supporting 
documentation  and  the  documentac ion  is  correct. 


b.  Docuaen t a t ion  trouble  D  ;  .  The  software  does  not  operate  according  to  support¬ 
ing  documentation  but  the  software  operation  is  correct. 

.  Design  trouble  (E,1.  The  software  operates  according  to  supporting  documentation 
bur  a  design  deficiency  exists. 
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operat lonal  symptom  but  with  the  potential  of  creating  trouble. 

5. 8. 5. 2  Software  trouble  report  priority.  Software  errors  are  prioritizes 
as  follows: 

a.  Priority  1  -  An  error  which  prevents  the  accomplishment  of  an  operat: 
mission  essential  function  in  accordance  with  official  requirements  1 
a  program  stop)  ,  which  interferes  with  an  operator  to  the  extent  that 
tor  prevents  the  accomplishment  of  an  operational  or  mission  essentia 
or  which  Jeopardizes  personnel  safety. 

b.  Priority  2  -  An  error  which  adversely  affects  the  accomplishment  of  an  operation 
al  or  mission  essential  function  in  accordance  with  official  requirements  so  as 
to  degrade  performance  and  for  which  no  alternative  work-around  solution  exists, 
or  which  interferes  with  an  operator  to  the  extent  that  the  operator  adversely 
affects  the  accomplishment  of  an  operational  or  mission  essential  function  so  as 
to  degrade  performance  and  for  which  no  alternative  work-around  solution  exists. 
(Reloading  or  restating  the  program  is  not  an  acceptable  work-around  solution..  : 

c.  Priority  3  -  An  error  which  adversely  affects  the  accomplishment  of  an  operation 
a  or  mission  essential  function  in  accordance  with  official  requirements  so  as 
to  degrade  performance  and  for  which  there  is  a  reasonable  alternative  work¬ 
around  solution;  or  which  interferes  with  an  operator  to  the  extent  that  the 
operator  adversely  affects  the  accomplishment  of  an  operational  or  mission 
essential  function  so  as  to  degrade  performance  and  for  which  there  is  a  reason¬ 
able  alternative  work-around  solution.  (Reloading  or  restarting  the  program  is 
not  an  acceptable  work-around  solution.) 

d.  Priority  4  -  Ar.  error  which  is  an  operator  inconvenience  or  annoyance  and  does 
not  affect  a  required  operational  or  mission  essential  function. 

e.  Priority  5  -  All  other  errors. 

5.8. 5. 3  Software  trouble  report  disposition.  The  contractor  shall  determine  the  ini¬ 
tial  status  of  each  STR  when  it  is  reported  and  shall  monitor  and  record  any  and  all 
changes  of  the  status  of  each  STR.  When  all  appropriate  action  concerning  an  STR  has 
been  completed,  the  contractor  shall  determine  and  record  the  final  disposition  of  the 
STR. 

5.9  Quality  assurance.  The  contractor  shall  implement  quality  assurance  procedures  to 
verify  in  each  stage  of  the  development  that  the  product  program  will  meet  the  current 
performance  specifications  approved  by  the  procuring  agencv.  The  contractor  shall  im¬ 
plement  quality  assurance  procedures  to  validate  the  accuracy,  correctness  and  perform¬ 
ance  of  the  product  programs,  to  verify  the  accuracy  and  conformance  of  program  docu¬ 
mentation  to  the  requirements  of  this  Military  Standard  and  to  ensure  that  all  procedures 
Incumbent  on  the  contractor  are  properly  and  completely  followed.  The  procedures  shall 
be  open  to  review  by  the  procuring  agency  or  ,ts  authorized  reoresentac 1 ve .  The  imple¬ 
mentation  and  functioning  of  the  procedures  shall  al9o  be  open  to  'nsDection  by  the 
procuring  agency  or  Its  authorized  representative. 

5.9.1  Quality  assurance  organization.  The  qualify  assurance  organization  shall  In¬ 
clude  provisions  for  addressing  all  the  following  facets  of  quality  assurance. 

5.9. 1.1  Reporting  level.  The  contractor's  quality  assurance  organization  shall  have 
corporate  report' ng  responsibility  external  to  the  developing/engineering  group  to  assure 
an  objective  evaluation  of  conformity  and  progress. 

5. 9. 1.2  Participation  in  audits.  The  contractor's  qualltv  assurance  organization  shal 
present  and  shall  conform  with  procedures  for  independent  quality  audits  that  should  take 
place  throughout  the  development  phase  starting  with  design  development  and  ending  with 
test,  certification,  delivery  and  acceptance  which  measure  svsten  conformance  with  tec- 
nical  and  management  requirements  and  standards. 
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5.9. 1.3  Design  reviews.  The  contractor's  quality  assurance  organization  shall  parti¬ 
cipate  in  design  reviews  and  design  walk-throughs  utilizing  procedures  to  assure  complete¬ 
ness  snd  accuracy  of  presented  materials  and  to  assure  timely  and  correct  completion  of 
action  assignments. 

5. 9. 1.4  Program  design.  The  detailed  performance  requirements  for  the  weapon  system 
software  shall  be  audited  and  examined  to  ensure  that  they  are  able  to  satisfy  Che  oper¬ 
ational  requirements,  operational  standards  and  system  performance  specifications,  as  may 
be  provided  by  the  procuring  agency.  The  detailed  design  of  the  weapon  system  software 
shall  be  examined  to  ensure  complete  compliance  with  the  performance  requirements  speci¬ 
fied  by  the  procuring  agency. 

5. 9. 1.5  Program  coding.  Coding  shall  be  examined  to  ensure  complete  compliance  with 
the  detailed  program  design  and  specified  programming  conventions  and  standards.  List¬ 
ings  for  developmental  components  of  the  program  shall  be  thoroughly  desk-checked  before 
testing. 

5. 9. 1.6  Tests.  The  contractor's  quality  assurance  organization  shall  witness  tests  to 
assure  conformance  with  approved  procedures.  Quality  assurance  activities  shall  include 
record-keeping,  maintenance,  control  of  test  materials,  and  conflict/discrepancy  resolu¬ 
tion. 

5.9. 1.7  Deliverable  Items.  The  contractor's  quality  assurance  organization  shall  pro¬ 
vide  quality  procedures  and  shall  monitor  conformance  with  all  procedures  to  assure  con¬ 
tractual  correctness  of  all  deliverable  Items. 

5. 9. 1.8  Reporting .  The  contractor's  quality  assurance  organization  shall  utilize  both 
interdepartmental  and  intradepartmental  reporting  chains  to  assure  prompt  reporting  of 
the  results  of  quality  related  activities.  Quality  assurance  shall  follow  up  any  noted 
discrepancy/action  assignment  to  assure  timely  and  complete  correction  of  the  problem. 

5.9. 1.9  Authority.  When  conflict  exists  between  quality  assurance  and  other  contractor 
functions  at  a  specific  task/management  level,  the  conflict  shall  be  resolved  success¬ 
ively  at  the  next  higher  level. 

5.10  Program  acceptance.  In  addition  to  any  criteria  specified  by  the  procuring 
agency,  program  acceptancs  shall  be  predicated  upon  satisfaction  of  system  reserve  re¬ 
quirements,  successful  completion  of  the  aoftwere  quality  test,  the  priority  and  maaber 
of  unresolved  software  and  doctmientatlon  errors  and  the  number  of  existing  patch  words. 

5.10.1  Reserve  requirements  for  program  acceptance.  Total  system  memory,  input  and 
output  channels,  and  processing  time  reserves  of  at  least  twenty  percent  shall  exist  at 
the  time  of  program  acceptance  by  the  procuring  agency. 

5.10.2  Software  quality  test  requirements  for  program  acceptance.  Prior  to  program 
acceptance,  the  program  shall  have  successfully  completed  the  software  quality  test. 

This  test  Is  Intended  to  exercise  all  of  the  functions  of  the  software  for  s  period  of 
time  In  order  to  demonstrate  that  the  software  is  reasonably  free  of  serious  or  numerous 
errors.  Under  this  test,  the  software  Is  to  be  stressed  to  the  limits  of  Its  designed 
capacities  and  beyond  In  order  to  ensure  that  degradation  at  the  point  of  saturation  is 
not  catastrophic. 

5.10.2.1  Test  environment.  The  software  quality  test  shall  be  conducted  In  the  en¬ 
vironment  specified  by  the  procuring  agency.  Normally,  the  software  quality  test  shall 
be  conducted  in  the  ultimate  user  environment  for  which  the  system  and  program  were  de¬ 
signed.  If  the  ultimate  user  environment  cannot  be  used  for  the  stress  portion  of  the 
software  quality  teat,  the  elternate  test  site  for  the  stress  portion  shall  be  a  fully 
Integrated  facility  equipped  with  the  same  hardware  found  In  the  ultimate  user  environment. 
The  remainder  of  the  software  quality  test  requirements  must  still  be  eat  in  the  ultimate 
user  environment  Including  the  length  of  test  as  specified  below. 


The  software  quality  test  shall  be  conducted  by  a  testing  activity  designated  by  the  pro¬ 
curing  egency  and  Independent  of  the  procuring  agency  and  the  development  con tr actor (s ) . 
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5.10.2.8  Software  qualicy  teat  reduced  capability  testing.  For  systems  designed  to 
operate  In  a  reduced  capability  mode(s)  due  to  hardware  fallure(s),  each  possible  reduced 
capability  mode  shall  be  validated  by  causing  actual  physical  degradation  of  the  hardware, 
e.g.,  secure  power  to  a  piece  of  equipment.  Correct  processing  of  the  failure  shall  be 

validated  including  the  capability  to  return  to  a  normal  mode  of  operation.  Scenarios 
while  operating  In  the  reduced  capability  oode(s)  shall  demonstrate  compliance  with  formal 
specifications.  The  duration  of  system  operation  in  the  reduced  capability  mode  shall  be 
determined  by  the  testing  activity. 

5.10.2.9  Software  qualicy  test  and  maintenance  support  programs.  On-line  organization 
level  hardware  maintenance  support  programs  shall  be  demonstrated  during  test  periods  of 
nominal  loading  when  such  a  capability  exists.  For  maintenance  programs  designed  to  op¬ 
erate  only  when  the  operational  program  is  off  line,  the  demonstration  of  these  mainten¬ 
ance  support  programs  will  not  be  included  as  part  of  the  test  of  the  operational  soft¬ 
ware,  but  as  a  separate  demonstration  to  the  satisfaction  of  the  testing  activity.  The 
priority  and  masher  of  unresolved  software  and  documentation  errors  and  the  number  of 
existing  patch  word  requirements  shall  apply. 

5.10.2.10  Errors  during  test.  Occurrence  of  a  software  error  of  a  priority  one  or  two 
severity  during  the  software  quality  test  shall  require  correcting  the  error  and  repeat¬ 
ing  the  test  In  its  entirety.  Occurrence  of  an  Intermittent  software  error  of  a  priority 
one  or  two  severity  shall  require  that  the  particular  operatlon(s)  be  repeated  several 
times  to  the  satisfaction  of  the  testing  activity  and  chat  the  full  test  then  be  repeated 
In  Its  entirety. 

5.10.3  Software  quality  test  limitations.  Specified  below  are  error  and  patch  limits 
relevant  to  the  programs  undergoing  the  software  quality  test.  These  limits  shall  be 
satisfied  prior  to  the  commencement  of  the  test.  In  addition,  errors  detected  during  the 
test  which  cause  this  criteria  to  be  exceeded  shall  invalidate  the  test;  an  individual 
test  may  continue  to  run  to  its  planned  completion  In  order  to  uncover  any  additional  er¬ 
rors.  In  those  tests  where  the  error  limits  are  exceeded,  the  test  shall  be  rerun  In  Its 
entirety.  In  those  tests  where  the  patch  limits  are  exceeded,  consequently  requiring 
source  level  changes  and  recompilation  or  assemblage,  the  test  shall  be  rerun  It  Its  en¬ 
tirety. 

5.10.3.1  Error  limits.  The  following  error  limits  apply. 

a.  The  number  of  unresolved  software  errors  (excluding  documentation  errors)  shall 
not  exceed  the  following:  (see  paragraph  5. 8. 5. 2  for  definition  of  priorities) 

Severity  Limits 

Priority  1  and  2  (high)  Zero 

Priority  3  (medium)  One  per  70K  of  machine  Instruction  words  or  fraction 

thereof . 

Priority  4  and  5  (low)  One  per  35K  of  machine  Instruction  words  or  fraction 

thereof. 

b.  Intermittent  errors  shall  bs  Included  in  the  count  of  software  errors  and  re¬ 
ceive  no  special  consideration. 

c.  The  nueber  of  unresolved  technical  errors  In  all  of  the  deliverable  docueenta- 
tlon  shall  not  exceed  the  stm  of  three,  plus  one  for  every  25K  of  machine  In-  * 
structions  or  fraction  thereof.  For  example,  a  program  having  300K  machine  In¬ 
structions:  3  ♦  12  ■  15  allowable  documentation  errors. 

d.  All  software  errors  discovered  during  the  software  quality  test  shall  be  docu¬ 
mented. 

5.10.3.2  Patch  limits.  The  following  patch  limits  apply. 
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a.  The  total  number  of  patch  words  In  a  program  shall  not  exceed  0.005  times  the 
total  machine  Instruction  words  In  the  program. 

b.  There  shall  be  no  patching  of  errors  while  the  software  quality  test  is  In  prog¬ 
ress. 

c.  Patches  which  correct  software  errors  are  permitted  only  if  they  have  been  In¬ 
corporated  Into  the  configuration  Item  and  are  automatically  applied  during  the 
load  process. 

d.  The  only  other  patches  that  may  be  in  a  program  during  the  software  quality  test 
are  those  which  are  considered  required  for  testing  purposes  and  they  shall  be 
specifically  sec  forth  In  the  test  procedures.  Caution  should  be  exercised  that 
these  pstches  do  not  Interfere  with  the  validity  of  the  software  quality  test 
results.  These  pstches  shall  not  be  counted  against  the  patch  limits  established 
above . 

e.  All  patches  shall  be  documented. 

5.11  Configuration  management.  The  contractor  shall  develop  and  implement  Internal  pro¬ 
cedures  to  ensure  the  positive  identification,  control  and  status  accounting  of  the  con¬ 
figuration  of  the  weapon  system  software,  the  detailed  program  performance  requirements 
and  the  detailed  design  requirements  during  all  phases  of  the  development  effort.  The 
contractor  shall  ensure  chat  such  procedures  ere  integrated  with  the  configuration  manage¬ 
ment  procedures  addressing  the  total  weapon  system.  Procedures  shall  provide: 

a.  Positive  identification  of  all  program  components. 

b.  Rapid,  comprehensive  and  accurate  treatment  of  proposed  changes  to  components 
under  configuration  control. 

c.  Comprehensive  implementation  of  approved  changes  and  dissemination  of  corrected 
documentation  and  program  changes. 

d.  Accurate  records  of  status  of  all  proposed  changes. 

e.  Verifications  of  change  control,  identification  and  status  accounting  of  the 
descriptive  doctaaentatlon  and  program  materials. 

5.11.1  Configuration  Identification. 

5.11.1.1  Baselines.  The  contractor  shall  establish  Internal  baselines  representing 
the  approved  configuration  identification  of  the  weapon  system  software.  Internal  base¬ 
lines  shall  be  established  to  ensure  orderly  transition  from  one  software  development 
phase  to  the  next.  Internal  baselines  shall  be  established  at.  those  points  where  It  Is 
necessary  to  define  Internal  departure  points  for  future  changes  in  performance,  design, 
and  related  technical  requirements. 

5.11.1.2  Docventatlon  Identification.  The  contractor  shall  establish  titling,  lab¬ 
eling,  numbering,  and  cataloging  procedures  for  all  computer  software  documentation  and 
program  materials  which  satisfy  the  following  criteria: 

a.  Denotes  the  component  to  which  it  applies* 

b.  Describes  the  purpose  of  the  document. 

c.  Defines  the  baseline  which  It  la  a  part  of,  or  In  support  of. 

d.  Denotes  the  serial,  edition  and  change  status  of  the  document. 

The  compilation  date  shall  be  Indicated  as  part  of  the  Identifier  for  each  delivered 
component.  Sequence  nvobering  of  all  source  records  In  a  module  shall  be  structured  so 
future  changes  to  any  component  can  be  properly  noted. 
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3.11.2  Configuration  control.  Th«  contractor  (hall  aatabliah  procaduraa  for  tha  formal 
control  of  all  dociaents,  program  materials  and  the  development  support  library.  These 
procedures  shall  Include  bringing  each  component  of  the  software  under  configuration  con¬ 
trol.  These  procedures  shall  also  Include  the  establishment  and  functioning  of  a  soft¬ 
ware  configuration  control  board  and  the  methods  and  formats  for  submission  and  acting  on 
software  change  proposals,  software  enhancement  proposals  and  software  trouble  reports. 

5.11.2.1  Software  changes.  During  software  development,  changes  proposed  by  the  con¬ 
tractor  to  the  software  (Including  descriptive  documentation)  which  Is  under  configuration 
control  by  the  contractor  or  the  Government  or  both,  shall  be  submitted  to  the  appropriate 
software  configuration  control  board(s)  as  either  Software  Change  Proposals  (SCP)  or  Soft¬ 
ware  Enhancement  Proposals  (SEP)  depending  on  the  classification  of  the  changes.  All  SCPs 
or  SEPs  which  have  cost.  Interface,  or  schedule  Impact  shall  be  attached  to  a  form  DD1692 
(Engineering  Change  Proposal,  page  1)  completed  and  mmbered  In  accordance  with  reference 
2.1. a  and  submitted  to  the  procuring  agency. 

5.11.2.2  Documentation  changes.  Procedures  for  controlling  the  preparation  and  dis¬ 
semination  of  changes  to  documentation  to  reflect  approved  and  Implemented  SCPs,  SEPs, 

and  STRs  shall  be  developed.  Such  procedures  shall  be  designed  to  Insure  the  simultaneous 
promulgation  of  the  descriptive  dociasentation  and  program  materials. 


5.11.2.3  Software  Configuration  Control  Boards  (SCCB).  Each  baseline  plus  approved 
changes  from  those  baselines  shall  be  under  the  formal  control  of  a  responsible  board. 

The  board  shall  Identify  and  maintain  the  complete  and  current  description  of  each  com¬ 
ponent  of  the  weapon  system  software.  The  board  shall  consider  all  proposed  changes  to 
the  baseline  and  take  appropriate  action  on  each  proposal.  Each  proposal  shall  be  ana¬ 
lyzed  and  evaluated  In  the  following  areas: 

a.  Operational  Impact. 

b.  Technical  design  Impact. 

c.  Resource  requirements  (e.g.,  cost,  personnel,  time). 

For  all  approved  changes,  the  board  shall  ensure  Implemented  changes  are  reflected  in  all 
baseline  documentation.  The  contractor's  SCCB  shall  Implement  procedures  which  reconcile 
the  configuration  status  accounting  reports  and  the  status  of  the  software  with  the  ap¬ 
proved  baaellne(s)  and  Its  approved  changes. 

3.11.3  Configuration  status  accounting.  Tha  contractor  shall  establish  procedures  to 
enable  the  generation  of  periodic  status  reports  on  all  components  under  configuration 
management.  These  procedures  shall  Identify  all  SCPs,  SEPs,  and  STRs  in  preparation,  in 
review,  and  in  the  current  stage  of  Implementation.  These  procedures  shall  confirm  the 
Incorporation  of  approved  configuration  changes.  These  procedures  shall  Identify  all 
disapproved  and  deferred  SCPs,  SEPs,  and  STRs. 

5.12  Management  control.  The  contractor  shall  determine  and  Implement  a  management 
system  for  the  development  effort  which  Is  acceptable  to  the  procuring  agency.  The  man¬ 
agement  of  the  development  shell  emphasise  efficiency  and  economy.  Clear  lines  of  auth¬ 
ority  and  responsibility  shall  be  established.  The  management  system  shall  provide  for 
the  coordination  of  all  facets  of  the  development  under  a  master  schedule  of  events  and 
milestones.  The  detailed  performance  requirements,  the  program  architecture  and  the 
detailed  program  design  will  be  subject  to  review  by  the  procuring  agency  at  scheduled 
milestones  in  the  program  development  cycle.  Milestone  dates  shall  be  established  for 
demonstrations  of  evolving  software  capabilities.  Such  demonstrations  srs  Intended  to 
provide  the  necessary  visibility  for  project  management  and  meaningful  output  for  product 
validation.  The  management  system  shall  provide  a  capability  to  monitor  the  progress  of 
the  development  by  means  of  regular  status  reports,  reviews  and  audits.  The  managsnent 
system,  including  planning  and  procedural  guidance  for  the  development  effort,  shall  be 
compiled  In  an  overall  plan  for  visibility,  formalization,  control  and  coordination  of 
the  development. 
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5.12.1  Management  organization.  The  contractor  may  uae  an  Internal  organization  of 
hla  own  choice,  subject  only  to  the  requirements  from  this  stendard  which  are  Invoked  by 
the  procuring  agency.  The  contractor  shall  designate  an  overall  manager  for  the  develop¬ 
ment  effort.  The  functions  of  design,  production  and  test  shall  be  given  organizational 
visibility.  The  relationship  of  all  support  functions,  both  full-time  and  part-time,  re¬ 
quired  to  support  the  development  effort  shall'be  clearly  defined.  The  responsibilities 
of  all  subcontractors.  If  used,  shall  be  clearly  visible  to  the  procuring  agency. 

5.12.2  Resource  requirements.  The  contractor  shall  determine  his  resource  requirements 
In  the  three  areas  of  personnel,  facilities,  and  equipment.  Planning  shall  be  completed 
early  enough  to  permit  orderly  acquisition,  installation,  and  training  (if  applicable)  of 
resources  on  an  optimum  schedule  to  prevent  delay  and  to  avoid  dead-time.  Reusability, 
permanency,  or  length  of  project  and  convenience  of  location  shall  be  weighed.  The  pro¬ 
curing  agency  may  direct  the  uae  of  government  or  other  facilities.  Planning  shall  be 
responsive  to  schedule  changes.  The  contractor  shall  avoid  sharp  fluctuations  In  per¬ 
sonnel  requirements  by  judicious  shifting  of  personnel  as  development  tasks  change. 


The  contractor  shall  consider  the  cost-effectiveness  of  commercial  equipment  to  assist  In 
the  development  where  appropriate.  The  possibility  of  continuing  use  of  the  equipment  by 
the  Government  during  the  operational  support  phase  of  the  software  life-cycle  shall  be 
a  consideration.  Where  weapon  system  equipment  Is  government-furnished  or  government- 
specified,  the  contractor  shall  be  responsible  only  for  the  cost-effectiveness  of  Its  use 
and  Mlntenance,  not  Its  acquisition.  The  contractor  shall  Implement  a  system  of  manage¬ 
ment  monitoring  of  utilization  In  the  areas  of  personnel,  facilities,  and  equipment  con¬ 
sidering  both  quantity  and  coat.  Actual  utilization  rates  shall  be  compared  to  predicted 
rates  at  least  monthly.  The  procuring  agency  may  specify  more  frequent  comparison.  Vari¬ 
ations  shall  be  expeditiously  Investigated  and  corrective  action  initiated.  Personnel 
stability  and  productivity  shall,  be  measured  regulsrly. 

5.12.3  Status  reviews.  Status  reviews  My  be  requested  by  the  procuring  agency  at  reg¬ 
ular  intervals  during  the  development  effort.  The  contractor  shall  be  able  to  provide  at 
these  reviews  the  current  status,  progress,  and  problems  occurring  In  the  development  ef¬ 
fort  within  the  purview  of  the  contractor. 

5.12.3.1  Status  review  subjects.  The  contractor  shall  address  the  following  subjects, 
as  appropriate  to  the  stage  of  the  development  effort.  In  each  status  review: 

a.  Organizational  changes,  Mnagerlal  personnel  changes 

b.  Design  status 

c.  Development  schedule  status  (mllestona  prognosis) 

d.  Coding  status 

e.  Software  Trouble  Report  (STR)  status 

f.  Software  Change  Proposal  (SCP)  status 

g.  Software  Enhancement  Proposal  (SEP)  status 

h.  Integration  schedule  status 

1.  Testing  status 

j .  Deliverables 

k.  Progress  on  previous  problsms 

l.  New  sctlon  Items /problems 

a.  Delinquencies:  governmental,  outside  contrsctor,  subcontrsctor,  end  Internal 

n.  Manpower  utilization 
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o.  Facilities  utilization 

p.  Computer  system  resource  utilization  (see  S.S.2) 

q.  Financial  suzmary. 

5.11.3.2  Status  review  subject  Items.  Within  each  subject  area,  the  contractor  shall 
cover  the  following  Items,  as  applicable: 

a.  The  schedule  updated  to  the  end  of  this  reporting  period. 

b.  Major  difficulties  encountered  and  plans  to  overcome  them.  Including:  Tasks/units 
that  are  currently  behind  schedule  (or  have  anticipated  schedule  changes) ,  their 
effects  on  completion  of  the  project,  and  steps  being  taken  to  remedy  schedule 
delays. 

c.  Other  information  which  defines  cause  and  effect  of  significant  changes  on  the 
contract  schedule. 

d.  Problems  which  actually  or  potentially  will  cause  deviation  from  contractual  re¬ 
quirements  . 

e.  Summary  of  meetings  and  conferences  held  during  the  reporting  period,  including 
acclon  items  with  due  dates  for  both  the  contractor  and  the  procuring  agency. 
Current  status  of  acclon  items  shall  be  included  until  reported  closed. 

3.12.3.3  Documentation  reviews.  Documents  and  programing  materials,  as  specified, 
shall  be  scheduled  for  detailed  review  prior  to  approval  or  acceptance.  The  purpose  of 
the  review  shall  be  to: 

a.  Verify  that  Che  subject  documents  and  programing  materials  comply  completely  and 
accurately  with  Che  program  performance  and  design  requirements  of  higher  level 
documents  and  programing  materials  and  all  other  standards  and  constraints  im¬ 
posed  by  che  procuring  agency. 

b.  Verify  the  accuracy  and  completeness  of  the  documents  and  programing  materials 
by  checking  for  all  components,  their  correct  cross-reference,  end  editorial 
accuracy. 

The  review  shall  be  in  two  stages:  a  preliminary  working-level  review  followed  by  a  formal 
(or  critical)  review  after  changes  resulting  from  the  preliminary  review  have  been  entered. 
Reviews  shall  be  scheduled  by  the  contractor,  with  the  concurrence  of  the  procuring  agency, 
and  in  accordance  with  milestones  in  the  software  development  plan.  The  procuring  agency 
may  designate  other  activities  to  participate  in  the  review.  The  contractor  shall  distri¬ 
bute  drafts  of  review  documents  and  programing  materials  to  each  designated  activity 
sufficiently  in  advance  of  the  scheduled  preliminary  review  to  allow  adequate  internal  re¬ 
view  by  each  activity.  The  contractor  shall  distribute  a  corrected  version  of  the  review 
documents  and  programing  materials  after  completion  of  the  preliminary  review.  The  crit¬ 
ical  review  foe  the  acceptance  or  approval  of  the  docvaients  and  programing  materials  shall 
expeditiously  follow  the  distribution  of  the  corrected  version. 

3.12.3.4  Special  reviews.  Special  reviews  may  be  scheduled  by  the  procuring  agency  et 
major  milestones  or  events  in  the  development  effort  not  covered  by  documentation  reviews 
or  statue  reviews.  A  special  review  of  the  test  program  as  developed  shall  be  conducted. 
The  contractor  shall  furnish  the  same  support  for  special  reviews  as  for  status  reviews. 

3.12.4  Inspections  and  audits.  The  procuring  agency  may  employ  a  physical  inspection  to 
determine  the  contractor's  conformance  with  contractual  requirements.  As  a  minimum,  areas 
of  Interest  include  docmantatlon  controls,  deliverable  data  items,  government-imposed 
standards,  and  the  following: 

e.  Facilities.  The  development  and  test  facilities  may  be  inspected  for  contractual 
conformity  at  any  time  during  the  life  of  a  software  system  development  contract. 
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Configuration  manatana nt.  Contractor  conformance  with  the  approved  software  con¬ 
figuration  management  requlraments  may  be  audited  through  examination  of  records 
and  attendance  at  software  configuration  control  board  meetings. 


Internal  standards.  The  procuring  agency  may  audit  the  contractor's  conformance 
with  Internal  standards  of  software  development  and  control. 


Quality  assurance.  The  procuring  agency  may  audit  and  inspect  the  contractor's 
conformance  with  the  approved  software  quality  assurance  requirements. 
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6.  MISCELLANEOUS 


6.1  Contract  Data  Requlreae nt».  Tha  following  list  of  Data  Itan  Descriptions  shall  ba 
utilized  if  the  procuring  agent  desires  to  order  data  that  la  generated  from  having  In¬ 
voked  pertinent  work  tasks  that  ara  established  within  this  standard.  Such  data  oust  be 
specified  on  the  Contract  Data  Requirements  List,  DD  Fora  1423. 
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Corresponding 

Section 


a. 

Interface  Design  Specification  (IDS) 

DI-E-2135 

5.1.2.4b, 

5. 1.2. Sc/S. 2. 3 

b. 

Prograa  Performance  Specification  (PPS) 

DI-E-2136 

5.1 

c. 

Program  Design  Specification  (PDS) 

DI-E-2138 

5.2 

d. 

Prograa  Description  docraent  (PDD) 

DI-S-2139 

5. 3/5. 4/5. 5 

e. 

Data  Base  Design  Document  (DBD) 

DI-S-2140 

5. 2. 2.6 

f. 

Prograa  Package  Document 

DI-S-2141 

5. 3/5. 4/5. 5 

S' 

Computer  Program  Teat  Plan 

DI-T-2142 

5.8 

h. 

Computer  Prograa  Test  Specification 

DI-l-2143 

5.8 

1. 

Computer  Prograa  Teat  Procedures 

DI-T-2144 

5.8 

J. 

Computer  Prograa  Test  Report 

DI-T-2156 

5.8 

k. 

Operator's  Manual  (OH) 

DI-M-2145 

5.7 

1. 

Systea  Operator's  Manual  (SOM) 

DI-M-2148 

5.7 

a. 

Software  Quality  Assurance  Plan 

DI-R-2174 

5.9 

n. 

Software  Configuration  Management  Plan  (SCMP) 

DI-E-2175 

5.11 

0. 

Software  Development  Plan 

DI-A-2176 

5.12 

P- 

Software  Change  Proposal  (SCP) /Software 
Enhancement  Proposal  (SEP) 

DI-E-2177 

5.11.2.2 

9- 

Computer  Software  Trouble  Report  (STR) 

DI-E-2178 

5.8.5 

Custodians: 

Preparing  Activity: 

Navy  -  MM 

Navy  -  NM 

Review  Activities: 

Project  No.  IPSC-N138 

Navy  -  AS,  EC,  MC,  OS,  SB 

User  Activities; 

Navy  -  NM,  AS,  EC,  MC,  OS,  SH 
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